Re: [RFC] Header organization of -base & -gui

[Nicola Pero]

> >Maybe gnustep/base originally was meant to provide that level of
> >indirection, allowing the gnustep-make system to switch between different
> >foundation libraries headers according to the library combo by simply
> >adding/removing -Ixxx/gnustep/base from the command line.  
> >
> You mean with an extra symlink Foundation pointing to .. ?

I mean maybe originally the whole Foundation/ directory was meant to be
installed inside gnustep/base.


> >   Unfortunately, the command line gets bigger on average - 
> >
> >   -I/usr/GNUstep/System/Library/Headers/gnu-gnu-gnu 
> > -I/usr/GNUstep/System/Library/Headers
> >
> Bummer, I was hoping to reduce these, because I believe the extra -I 
> entries are causing quite a performance hit on the preprocessor with all 
> these directories we allready have to search, for third party projects, 
> that might depend on even more external libs adding even more -I 
> entries.  But at least we're won't be getting worse than before.

Yes - I'd prefer to reduce the number of -I as well

 
> >   I now think this scheme (or some variant of this scheme) is what was 
> >   implemented, and the reason why gnustep/base existed.  Using gnustep/ 
> >   instead of gnu-gnu-gnu/ bounds gnustep-base and gnustep-gui together,
> >   which prevents library-combos such as gnu-fd-gnu (or apple-gnu-apple)
> >   from working.  Frankly, that does not seem an important matter as those
> >   will probably never work anyway, but if we go that route, then maybe
> >   we should consider simplifying the library combo into gnu-gnu (that is,
> >   {runtime library}-{base/gui library}) rather than gnu-gnu-gnu (that is,
> >   {runtime library}-{base library}-{gui library}).
> >
> I figured that apple-apple-gnu could be interesting, but I really see no 
> practical value.  (Just extra incompatible .gorm files and other 
> NSCoding archives.)  But what's with gnu-fd-gnu? Also, if I'm 
> considering GDL2 and GSWeb (if Apple ever releases EOF and WebObjects as 
> ObjC Frameworks again) would have similar issues.  On the otherhand that 
> is rather academic in my view.  I think reducing the lib-combo is fine.
> 
> But while we're at it, what's the real value of apple-gnu? And as 
> gnu-apple is rather unlikely, maybe we should reduce it to just gnu / 
> apple / fd?  Or is it necessary to maintain apple-fd and gnu-fd?  (These 
> questions aren't meant be rhetorical.)

At the moment, the apple GUI only works with the Apple base library, the
GNUstep GUI only works with the GNUstep base library (even if originally
that was not necessarily meant to be the case), and the libFoundation base
library only works with no GUI ('nil' GUI).

This means the only really allowed library combos are at the moment

 *-gnu-gnu
 *-apple-apple
 *-fd-nil

(where '*' is 'gnu' or 'apple').  So, you've really only got the following
possibilities:

 gnu-{gnu-gnu}: Using GNUstep with the GNU runtime.
 apple-{gnu-gnu}: Using GNUstep on a Darwin OS with Apple runtime, but no 
                  Apple FoundationKit/AppKit.

 apple-{apple-apple}: Using Apple stuff with the Apple runtime: OSX.
 gnu-{apple-apple}: Not used at the moment, if Apple ports their stuff
                    to the GNU runtime, that would be it.

 gnu-{fd-nil}: libFoundation with the GNU runtime, no GUI.
 apple-{fd-nil}: libFoundation with the Apple runtime, no GUI.

I'm not sure how much a simplification would be to rename

 *-gnu-gnu     into *-gnu
 *-apple-apple into *-apple
 *-fd-nil      into *-fd

we loose some future flexibility (not clear if we'll need it though), I'm
not sure how much we gain.  Maybe it would be easier to understand for
users.  I suppose someone might run X Windows on Apple, and be interested
in using apple-apple-gnu, maybe we don't want to rule out that
possibility.

But I'm definitely for keeping all the currently realistical and available
possibilities, which means not shrinking it down to just gnu / apple / fd.