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

[Nicola Pero]

My personal feeling is that the best organization would be the following:

* with library-combos (non-flattened gnustep) enabled:

 Headers/gnu-gnu-gnu/Foundation/
 Headers/gnu-gnu-gnu/GNUstepBase/
 Headers/gnu-gnu-gnu/AppKit/
 Headers/gnu-gnu-gnu/GNUstepGUI/
 Headers/gnu-gnu-gnu/Renaissance/
 Headers/gnu-gnu-gnu/AnyLibrary/

 Headers/gnugc-gnu-gnu/Foundation/
 Headers/gnugc-gnu-gnu/GNUstepBase/
 Headers/gnugc-gnu-gnu/AppKit/
 Headers/gnugc-gnu-gnu/GNUstepGUI/
 Headers/gnugc-gnu-gnu/Renaissance/
 Headers/gnugc-gnu-gnu/AnyLibrary/

 Headers/apple-apple-apple/GNUstepBase/
 Headers/apple-apple-apple/GNUstepGUI/
 Headers/apple-apple-apple/AnyLibrary/

 Headers/gnu-fd-nil/Foundation/
 Headers/gnu-fd-nil/AnyLibrary/

On the command line, the single flag -Ixxx/Headers/$LIBRARY_COMBO is used.  
Please note that -Ixxx/Headers/ is *not* passed on the command line.

With library-combos, you can have support for multiple library-combos on
the same GNUstep installation.

That means for example that you can compile, run, install both
apple-apple-apple (that is, Apple OSX native) and gnu-gnu-gnu (GNUstep
native) and apple-gnu-gnu (GNUstep built on top of Apple runtime) and
apple-fd-nil (libFoundation built on top of Apple runtime) and
gnugc-gnu-gnu (GNUstep built on GNU with garbage collection)  
applications / libraries / frameworks in the same GNUstep installation on
Mac OS X, and they would share the same directory layout.

I very much like using library-combos (such as 'gnu-gnu-gnu') instead of
`gnustep' as header directories because they make clear, at least to an
advanced user, what we are talking about.  They are consistent with the
names/directories we use for object files.  People who don't need
library-combos (most of them) can just --enable-flattened in
gnustep-make's ./configure and forget about them.  People who need
library-combos have a single unified way of organizing headers and
libraries and frameworks and applications.  It will also help future
changes (such as simplification or advancements of library-combo support)
to be made consistently and simply on all areas.


* with library-combos disabled:

[Headers/Foundation/]
 Headers/GNUstepBase/
[Headers/AppKit/]
 Headers/GNUstepGUI/
 Headers/Renaissance/
 Headers/AnyLibrary/

On the command line, only -Ixxx/Headers/ is used.  
-Ixxx/Headers/gnu-gnu-gnu/ is *not* passed on the command line.

In this mode, library-combos are disabled.  You have a single
library-combo system.

==

The existing options (--enable-flattened and --enable-multi-platform) in
gnustep-make's ./configure should be enough to support this.

Maybe we could change the default as Adam seems to suggest, and make the
default --disable-flattened and --disable-multi-platform.

That seems still open to discussion.  Opinions on that ?





> Configuring with --enable-multi-platform allows someone to use both gc 
> and non gc versions of gnustep simultaniously. (Actually is that true? 
> Can you install two runtime versions of the ObjC runtime?  But that's 
> irrelevant here because the corresponding gnustep libraries could be 
> installed on the same fileserver.)

--enable-multi-platform as it is now has nothing to do with using gc and
non-gc versions of gnustep at the same time; I assume you are talking of 
a future proposed implementation.

Still I'd like to point out that at the moment, even if you use
--disable-multi-platform (which is the default), you can still use
library-combos.

You can use

export LIBRARY_COMBO=gnugc-gnu-gnu
. /usr/GNUstep/System/Library/Makefiles/GNUstep.sh

to start up a gnugc-gnu-gnu environment.  And you can use

. /usr/GNUstep/System/Library/Makefiles/GNUstep-reset.sh
export LIBRARY_COMBO=gnu-gnu-gnu
. /usr/GNUstep/System/Library/Makefiles/GNUstep.sh

to switch back to your gnu-gnu-gnu environment.

--enable-multi-platform has no influence on this at the moment.



> I know I only checked very few projects, but I get the feeling, that the 
> impact of the change is a lot less than I originally feared.

Yes.  I wouldn't be much afraid of this change.