This question about Developing extensions (plugins skins etc.): Answered
include in MANIFESTs
I am finishing a script to process the distributed files in an installed wiki; parsing MANIFESTs seems the way to go. (The script handles permissions policies, including
SeLinux stuff, so the MANIFEST provides the list of files & standard permissions - and other stuff - more on that later in another topic. I promised to release this a while ago, and it will probably turn into a feature proposal. For now, trust that I'm doing something sensible and need to understand how MANIFESTs are supposed to work.)
I'm confused by includes.
trunk/core/lib/MANIFEST contains includes, e.g.
!include ../EditTablePlugin/lib/Foswiki/Plugins/EditTablePlugin
but under svn
EditTablePlugin isn't in core/, it's in trunk. E.g.
trunk/EditTablePlugin/lib/Foswiki/Plugins/EditTablePlugin/MANIFEST exists in an svn checkout, and
<pre>lib/Foswiki/Plugins/EditTablePlugin/MANIFEST is actually installed.</pre>
http://foswiki.org/Extensions/BuildContrib#MANIFEST doesn't have the ../ syntax, but does mention the package name before lib/...
(TWiki looks the same, and yes, I'm still dealing with it, too)
So what is the
../ supposed to be relative to? Is this an artifact of the build process, or something significant in real life?
Is it safe to just strip
../<word>/ and assume that all includes are relative to the installation root?
Or maybe I should simply do a File::Find::find on MANIFEST in the entire installation tree, and ignore include alltogether?
I'd rather not assume...so could someone authoritiative explain what's really going on?
Thanks.
--
TimotheLitt - 22 Jul 2011
Unfortunately we don't ship a complete Manifest file with Foswiki. The "include" statements reference the individual MANIFEST files in each extension, however they don't get packaged/shipped with Foswiki. If you are working with a SVN checkout, then those files will be found. The
../ is relative to the "core" directory, as the extension source is relative to one level up from core. The build is run from the core directory, so everything is relative from there, not the lib directory containing the MANIFEST file.
See
Tasks.Item8898 and some other related Manifest issues / enhancements are listed under
Tasks.BuildContrib
--
GeorgeClark - 22 Jul 2011
Uggh. I was afraid of that. Shipping a file with relative references to a directory that isn't shipped isn't very social...
Real story at
Development.SecurityChecklists. Perhaps that will encourage work on the other issues...
Thanks.
--
TimotheLitt - 23 Jul 2011