Re: Upcoming releases

[Nicola Pero]

> >>I hope to make the next unstable release(s) of the core libraries, 
> >>probably starting Tuesday night.
> >>    
> >>
> >Let us know when it would be the right time to make the header
> >installation dir updates.
> >
> >It seems it would be the last major filesystem layout change, so I'd like
> >to get that in soon and then we can keep the filesystem layout we have
> >unchanged forever :-)
> >  
> >
> I'm still ready to do the work, but Tuesday is a bit tight for me.  
> Besides, we still have to decide on [...]

I'd like to do this change now, in the timeslot between this release and
the next one, as recommended by Adam.

As far as I am aware, we have reached a complete decision already (except
for some details).

The main enhancements we are trying to implement are:

 - better support for multiple library-combos when library-combos are
used.  Ideally I'd like a developer to be able to use Apple FoundationKit,
gnustep-base and gnustep-base with GC and libFoundation all at the same
time on the same system.  At the moment it doesn't really work well with
headers.

 - smaller compiler command-line reducing the number of -Ixxx options
passed to the compiler.  That speeds up compilation and makes everything
easier to understand.

 - easier transition between GNUstep libraries and Apple frameworks:
simplifying compiling gnustep-base-additions as a framework on Apple and
making possible to write code which can #include gnustep-base-additions
headers in such a way that it works no matter if gnustep-base-additions is
a GNUstep library or an Apple framework.

The main downside of the proposed change is:

 - slightly increased number of top-level directories in Headers/.  In
practice, all directories which were previously in Headers/gnustep/ now
would be top-level in Headers/.  That probably adds around 10 new
top-level directories for a full install with quite a lot of non-essential
stuff.  I don't see a way to avoid this unless we compromise the
enhancements we're trying to achieve; what we can do is to try to reduce
the problem by rationalizing header installation (not installing private
headers, and other rationalization such as putting all gnustep-base
headers either in Foundation/ or in GNUstepBase/, so unicode/ would *not*
be a top-level directory, but inside one of those two), and keeping in
mind that stuff which will never be used as a framework (such as gnustep
backends) does not need to be all top-level: all gnustep backend headers,
when installed, might be in GNUstepBack/{backend-name}/ rather than having
separate top-level dirs for each backend.  Using those things together
would already reduce clutter considerably.

The proposed steps are:

 1. make --enable-flattened the default (done!)

 2. if library-combos are used, modify gnustep-make to install all headers
in Headers/$LIBRARY_COMBO/ rather than Headers/, and look for headers
there. (leaving -Ixxx/gnustep/ in place for the moment being).

 3. modify gnustep-base and gnustep-gui to install headers in:

    {header dir chosen by gnustep-make}/Foundation/
    {header dir chosen by gnustep-make}/GNUstepBase/
    {header dir chosen by gnustep-make}/AppKit/
    {header dir chosen by gnustep-make}/GNUstepGUI/

    the reason why those libraries are to be done first is that they
    compose the library-combo - having them in library-combo keyed 
    directories when library-combos are used is one of our targets.

    If you want to rearrange the headers inside the gnustep-base 
    source tree itself, this would be a good occasion.

    Update all callers/users of gnustep-base-additions to include
    headers using #include <GNUstepBase/Xxx.h>.

 4. modify other core libraries to not rely on gnustep-make providing
    a -Ixxx/gnustep/ flag automatically.

    The very quick fix is just to modify the libraries to install headers 
    in {header dir}/{name} rather than {header dir}/gnustep/{name}.

    That might be enough for some of the core libraries; but in general, 
    it might be a good occasion to update names too, switching from a 
    short-name form ("guile", "java", "x11", "xlib") to a long-name form 
    ("GNUstepGuile", "GNUstepJava", "GNUstepBack/X11", 
    "GNUstepBack/XLib"), installing headers in {Headers}/{LongName}/
    rather than {Headers}/gnustep/{short-name}, and updating all
    #includes.

 5. Remove the -Ixxx/gnustep flag from gnustep-make.


I'm now starting to work on 2; you could give a try at 3 if you like.