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

[Nicola Pero]

> >> The files are all part of the base library, not additions to it
> >
> > In some cases, it might make sense to use/compile only parts of it as 
> > with the apple-apple-* combo. 
> 
> Let me try to clarify this.  -base implements the FoundationKit as 
> defined by OPENSTEP plus many of the extensions found in the current 
> Cocoa Foundation.  To be compatible in the sense that "user" code can 
> compile code against both Apple's Foundation and -base, -base installs a 
> directory called Foundation which includes all NS*.h files also found in 
> Cocoa's Foundation.
> 
> Now gnustep-base has extensions of it's own (GSMime, GSXML, ...) In all 
> *-gnu-* variants of -base (ie. when the "Foundation-compatible" library 
> is gnustep-base, these extensions are compiled into libgnustep-base 
> library.  For apple-apple-* -base offers the possibility to be compiled 
> with add=yes so that only the extensions are compiled into a library 
> calls libgnustep-baseadd.
> 
> Independant of these two configurations, the public headers of these 
> gnustep extensions should all be installed in Headers/gnustep/base (This 
> is currently the case for most GS*.h files but not for all.)  There 
> should be no reason to installl any GS*.h headers into Foundation.  My 
> proposal was to fix the GS*.h headers that are currently installed in 
> Foundation to be installed to gnustep/base where they belong

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!

Compiling Additions as a framework on OSX, rather than a library, sounds
like a good idea - it is what I would do.  It's quite natural as
frameworks seem to be more natural than libraries on OSX; it's very
natural since you can then distribute the binary framework and people drop
it in their frameworks directory and can use it as it is from OSX native
tools.

So, if you rename gnustep/base/ to be something like GNUstepBase/, then:

 - on *-gnu-*, gnustep-base contains both -base and -baseadd, and -baseadd
headers are installed in GNUstepBase/, while standard -base headers in
Foundation/.  -baseadd is a subproject of -base so effectively while the
headers are installed in different locations, it's a single library.

 - on *-apple-*, -baseadd is compiled standalone as a framework called
GNUstepBase.

In both platforms, the headers of the standard OpenStep FoundationKit are 
found with 

#include <Foundation/NSXXX.h>

while the headers of -baseadd are found with

#include <GNUstepBase/GSYYY.h>

The only difference is that on *-apple-* you need to link explicitly
against the framework GNUstepBase (that is easy to do from within PB, and
from within gnustep-make as well).  But that's always the case, and if
it's a framework, it's likely to be easier than if it's a library.

One reason I'd like to get rid of the gnustep/base/ directory (and all
gnustep/ directories in general) is that I'd like if gnustep-make could do
without adding

-I/home/nicola/GNUstep/Library/Headers/gnustep 
-I/usr/GNUstep/Local/Library/Headers/gnustep 
-I/usr/GNUstep/Network/Library/Headers/gnustep 
-I/usr/GNUstep/System/Library/Headers/gnustep

to the compiler command line on *-gnu-*.  That would be an improvement for
all *-gnu-* users!

I stress that this proposal is only a sketchy starting point; for example
all the other gnustep libraries installing stuff into gnustep/*/ would
have to be changed to, and GNUstepBase might not be the best name/header
directory.