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

[Nicola Pero]

> Yes - good summary - I agree but let me say that there is no special
> reason why the directory should be called gnustep/base.  Actually, I have
> reasons to argue that it should *not* be called gnustep/base, and that we
> should change that name!

Hmmm.  It's more complex than that I suppose - I seem to have missed the
main point.  gnustep-make is supposed to support library-combos, which
allow you to have libraries and tools compiled against different
foundation libraries (for example, gnu-gnu-gnu or apple-apple-apple or
gnu-fd-nil) kept on the same directory structure;  switching between
library-combos should switch between the library versions, preventing
confusion.

That works for object files because they are put in library-combo keyed
directories.

It seems library headers do not need to be different for different library
combos.  After all, headers can use #ifdef GNUSTEP and similar stuff to
use different code when compiled with different base libraries if that's
the matter.  That's why we install a single version of headers whenever
you install a library.  We don't key headers inside library-combo
directories at the moment.

But to be completely honest, Foundation/ is an obvious exception.  If you
want to #include <Foundation/Foundation.h> when compiling for
apple-apple-apple or for gnu-gnu-gnu (or for apple-gnu-nil or gnu-fd-nil),
you want different headers to be included.

I suppose if you have two different foundation libraries on your system
(say, apple and gnu on OSX), and want to switch between them by using a
library combo, I suppose the Foundation/ directory should not be top-level
in the installed Headers/ directory, but hidden below a partial
library-combo subdir, so that gnustep-make can activate only the correct
Foundation headers by adding the appropriate -I, making sure only the
correct Foundation headers are used.

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.  At the moment
this looks like totally broken, as Foundation/ is installed just below
Headers/, so whenever gnustep-base is installed in a gnustep-make
directory tree, no other foundation library can be used.

I suppose we've got the following solutions:

 * put all headers in a library-combo subdir.

  /usr/GNUstep/System/Library/Headers/gnu-gnu-gnu/Foundation/
  /usr/GNUstep/System/Library/Headers/gnu-gnu-gnu/AppKit/
  /usr/GNUstep/System/Library/Headers/gnu-gnu-gnu/Renaissance/
  /usr/GNUstep/System/Library/Headers/gnu-gnu-gnu/Yyy/
  /usr/GNUstep/System/Library/Headers/gnu-gnu-gnu/Xxx/

  /usr/GNUstep/System/Library/Headers/apple-apple-apple/Renaissance/
  /usr/GNUstep/System/Library/Headers/apple-apple-apple/Yyy/
  /usr/GNUstep/System/Library/Headers/apple-apple-apple/Xxx/

  /usr/GNUstep/System/Library/Headers/apple-gnu-nil/Foundation/
  /usr/GNUstep/System/Library/Headers/apple-gnu-nil/Renaissance/
  /usr/GNUstep/System/Library/Headers/apple-gnu-nil/Yyy/
  /usr/GNUstep/System/Library/Headers/apple-gnu-nil/Xxx/

  on the compiler command-line, you only have

  -I/usr/GNUstep/System/Library/Headers/gnu-gnu-gnu

  if you're working with gnu-gnu-gnu library combo.
  If you compile a library twice with two different library-combos, and
  install it twice, two copies of the headers are installed.

  If you don't like library-combos and are using a flattened directory
  structure, you simply don't see any library-combo at all.

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

   /usr/GNUstep/System/Library/Headers/gnu-gnu-gnu/Foundation/
   /usr/GNUstep/System/Library/Headers/gnu-gnu-gnu/AppKit/
   /usr/GNUstep/System/Library/Headers/Renaissance/
   /usr/GNUstep/System/Library/Headers/Yyy/
   /usr/GNUstep/System/Library/Headers/Xxx/

   /usr/GNUstep/System/Library/Headers/apple-gnu-nil/Foundation/
   /usr/GNUstep/System/Library/Headers/gnu-fd-gnu/AppKit/

   Unfortunately, the command line gets bigger on average - 

   -I/usr/GNUstep/System/Library/Headers/gnu-gnu-gnu 
-I/usr/GNUstep/System/Library/Headers

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

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