Re: [RFC] Header organization GNUstepBase

[David Ayers]

Richard Frith-Macdonald wrote:

> I think making it public means we are committing to maintaining it ... 
> ie keeping this API unchanged in future if at all possible.  In my 
> view, we should be trying to make sure that nothing we make public is 
> going to need to be changed later.
> That's not an argument against making it public in particular ... just 
> a general point of view I'd like to suggest as a general guideline for 
> this restructuring.


All right folks, I'm finally done and I have a good feeling about this 
after installing more GNUstep apps than ever before :-)
I'll do this on a per-lib-basis...

Source structure: core/base
Headers/Foundation
Headers/Additions/GNUstepBase
Headers/Additions/GNUstepBase/unicode

Headers/Additions/GNUstepBase: (installed in $(GNUSTEP_HEADERS)/GNUstepBase)
Public:
GCObject.h
GNUstep.h
GSCategories.h
GSConfig.h.in
GSFileHandle.h
GSIArray.h
GSIMap.h
GSLocale.h
GSMime.h
GSObjCRuntime.h
GSUnion.h
GSXML.h
Unicode.h
behavior.h
objc-gnu2next.h
preface.h
preface.h.in

Privat, but need for -base and -add
thr-mach.h
DistributedObjects.h
GSFormat.h
GSInvocation.h
UnixFileHandle.h
WindowsFileHandle.h
config-win32.h (This seems to be obsolete)
config.h.in

I've been thinking about whether to put these in Source/Additions and 
#include "Additions/file.h",

The following headers will no longer be installed:
mframe.h
DistributedObjects.h
objc-load.h


I take it the other (NS*, AppKit* & unicode) headers are obvious.