gnustep-make bundle resources roadmap

[Nicola Pero]

Ok - I've got more or less clear my ideas about how to
complete/implement/extend the everything-has-a-resource-bundle support in
gnustep-make.  I thought it was easier, but there are lots of bits.  
Anywhere, here is more or less the roadmap.

1. I will add a new project type, something like 'resource-files'.  This
will simply install a list of resource files in a certain location.  We
have quite some places in the core libraries themselves where we need that
(such as Images in the gui etc).  Advantages of having a new project type
for this - 

 - code reuse; we no longer write the code to install the resources from
   scratch every time.

 - optimizations/flexibility; the code will have two different ways of
   installing resources - normal way, and GNUSTEP_DEVELOPER=YES way,
   which assumes you are developing and so only installs files which
   are newer than the already installed version.  This dramatically cuts
   down installation times.

 - project type possibly available from Project Center at some point in
   the future.

2. applications, bundle, gswbundles (possibly if I find the time to do
   it), gswapplications (possibly if I find the time to do it),
   frameworks will use all the same bundle code, but for copying
   resources into the bundle wrapper, and to install the bundle wrapper.
   symlinks are going to make this more complicated than it looks at
   first sight - but it should be possible.  I'll try then to optimize
   the shared bundle makefile fragment so that it only copies into
   the resource bundle files which are newer than the version in the
   resource bundle.  This should speed up building bundles considerably.
   The same makefile fragments to be used by tools and libraries to 
   produce their resource bundles (again this is slightly different than
   the other ones but should be manageable).

3. subprojects will have a resource bundle too.  if you add resources to
   a subproject, they will be put into a subproject resource bundle.
   
   the shared bundle makefile fragment used by everything (see point 2.)
   will copy resources from each subproject resource bundle into the
   instance project bundle.

   all the framework-specific code to manage subproject resources will 
   be removed.  the new code - while potentially less efficient, can
   be used by all project types (so *any* project type can have
   subprojects and resources in subprojects which are merged into
   the main bundle - not only frameworks), and once it's all working,
   I can try optimizing that again, making sure only resources which
   change are copied.  That might make it even faster than the original
   code - but I've not yet really thought about doing it, so don't count
   on this to work or on me doing it quickly.

4. standard projects will support a new option 

   xxx_COPY_INTO_LOCAL_BUNDLE = MyApp.app/Resources

   which, when the project is built, will copy the result into the
   specified bundle - and disable installation.  This allows you 
   to put bundles into applications for example (just xxx_COPY_INTO_LOCAL_BUNDLE
   each bundle into the application main bundle); or to put tools 
   into applications (same), or to put tools into bundles, or to put a
   tool into a bundle, and that bundle into an application.  More generally,
   you will be able to bundle anything inside anything :-) with
   an arbitrary recursion depth.  In particular, you can put tools
   into frameworks - even if you compile the tools against the framework!
   - and without any need for unmaintainable hacks inside gnustep-make.

   then, I will remove the framework tool specific code, since the new
   code, while again possibly slightly slower than the existing one, will
   be very general and can be used by any project type (which is just
   great).  Given enough time in the long term, I might have time to
   optimize that as well.

   The old framework tool API might not be easily available in the new
   organization, but since I think it's only used by one or two projects,
   it should not be difficult to update it to the new one.