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

[David Ayers]

David Ayers wrote:

> But back the issue at hand... Should we keep, or rather aim at 
> supporting apple-apple-gnu?
> - and therefor stop relying on the gnustep/base gnustep/gui header 
> indirection
> - with all the implications it has on NSCoding archives (but then 
> again we have the same issue with apple-apple-apple)

With further feedback from others and trying to walk through the 
problems of tweaking the apple-apple-apple to to fallback to use .gorm 
files if .nib files are unavailable and similar hacks, I must concede, 
that this is more of a hastle than it seems worth.  We would need our 
apps to support archives in formats for library combinations that have 
limited accessibility and the tweaking of the AppKit to enable loading 
apple-apple-apple .gorm files would force us to follow Apple's internal 
AppKit handling.  If a project, uses NSCoding archived UI and wants to 
be portable, I think it should provide .gorm files for gnu(gc)-gnu-gnu 
and .nib files for apple-apple-apple.

I'm also convinced that apple-apple-gnu is also not worth the trouble of 
keeping seperate .gorm archives and worrying about the integration of 
our -gui services (gpbs) with Apple's infrastructure.

I agree with Nicola, to keep the coupling of -base/-gui and 
Foundation/AppKit.   I still mean to clean up the install location of 
openstep/gnustep specific headers for -base/-baseadd and -gui/-guiadd 
into dedicated directories.  This will still break projects currently 
#include-ing <AppKit/GS*.h> and <Foundation/GS*.h> files.  (Well, I'll 
be providung those dummy headers so they won't really break during 
transition, but will emit warnings.)

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.)  On OS X --enable-multi-platform can 
also be used to install apple-gnu-gnu and apple-apple-apple.  The 
difference is, that in the latter variant, we don't have separate 
Foundation headers but we do in the former variant.  As soon someone 
also wants to install a libFoundation configuration, he would add 
another version of Foundation headers.  I haven't used libFoundation and 
I haven't seen where libFoundation installs it's headers and what it 
adds as -I entries.  On OS X you could --disable-multi-platform for 
gnustep choosing either apple-apple-apple or apple-gnu-gnu, yet still 
have to deal with the fact, that there are multiple sets of OpenStep 
headers for apple-gnu-gnu.  So I don't see I direct correlation between 
--enable-multi-platform and the handling of multiple OpenStep headers.

Therefor I propose the --enable-mulit-openstep configuration option.

But one question remains, should we also 'break' code which currently 
#include-s <gnustep/base/GS*.h> for the sake of allowing OS X users to 
build the additions subproject into a framwork with ProjectBuilder  or 
save our current users the trouble of transitioning where not necessary?

So here are two variants based on everyones feedback.  The first keeps 
the currently correct installed headers in the same place, the second 
would ease OS X / ProjectBuilder users to extract the subprojects into 
custom frameworks.

--enable-multi-openstep
- default on OpenStep systems (NeXT/OPENSTEP/OS X)

Variant 1:
Headers/gnustep/Foundation/NS*.h
Headers/gnustep/base/GS*.h
Headers/gnustep/AppKit/NS*.h
Headers/gnustep/gui/GS*.h
& -Ixxx/gnustep (only for *-gnu-gnu)

Variant 2:
Headers/GNUstep/Foundation/NS*.h
Headers/GNUstepBase/GS*.h
Headers/GNUstep/AppKit/NS*.h
Headers/GNUstepGUI/GS*.h
& -Ixxx/GNUstep (only for *-gnu-gnu)

--disable-multi-openstep
- default on all non-OpenStep systems.

Variant 1:
Headers/Foundation/NS*.h
Headers/gnustep/base/GS*.h
Headers/AppKit/NS*.h
Headers/gnustep/gui/GS*.h

Variant 2:
Headers/Foundation/NS*.h
Headers/GNUstepBase/GS*.h
Headers/AppKit/NS*.h
Headers/GNUstepGUI/GS*.h

The only fear I have, is that some developers using 
--enable-multi-openstep may start using #include 
<gnustep/Foundation/NS*.h> / #include <GNUstep/Foundation/NS*.h>.  But I 
see no other choice as simply documenting this as a bug.

Another issue with variant 2, has to do with the transition period, 
which would last at least until an official stable release.  The "new" 
GNUstep/ diectory will clash with the old gnustep/ on case insensative 
file systems.  *If* we chose that variant, this may call for some extra 
trickery during transition (and additional -I entries) but it should be 
solvable I believe.  Yet if it's too much of a hastle, I could imagine:
Headers/gnustep/Foundation/NS*.h
Headers/gnustep/AppKit/NS*.h
Headers/GNUstepBase/GS*.h
Headers/GNUstepGUI/GS*.h
& -Ixxx/gnustep (only for *-gnu-gnu)


Just to see what the impact would be, I quickly grep-ed through current 
cvs of a few projects to see how many files would be affected by the two 
variants.  The first number is number of files currently including 
GNUstep specific headers from AppKit/ or Foundation/ and the second 
number is the number of files currently including GNUstep specific files 
for gnustep/base/ or gnustep/gui.

Gorm - 3 - 0
ProjectCenter - 0 - 0
Renaissance - 1 - 0

GWorkspaces - 0 - 0
GNUMail - 0 - 0
Pantomime - 0 - 1
Preferences - 0 - 0
Terminal - 9 - 1

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.

I'd be glad to here alternative suggestions.

Cheers,
David

PS: and thanks for bearing with me :-)