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

[David Ayers]

Good spot!  So this is a "user" issue. :-/

Nicola Pero wrote:

> 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 suppose we've got the following solutions:
[snip]

> * put only the Foundation (and AppKit) headers in a library-combo subdir; 
>  
[snip]

>   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.

>   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.)

> * the hell with library-combos.  Let's drop them.  :-)  Just joking -
>   this would simplify things considerably, but it would downgrade a lot 
>   the flexibility and power of the system, which doesn't sound like a 
>   good idea.  People who don't want library-combos can use 
>   GNUSTEP_FLATTENED anyway.
>  
Well were almost there ;-) but I think to keep what's left could be 
worthwhile.

Cheers,
David