[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] Header organization of -base & -gui
From: |
David Ayers |
Subject: |
Re: [RFC] Header organization of -base & -gui |
Date: |
Mon, 07 Jul 2003 14:19:29 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030507 |
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 :-)
- Re: [RFC] Header organization of -base & -gui, (continued)
- Re: [RFC] Header organization of -base & -gui, David Ayers, 2003/07/03
- Re: [RFC] Header organization of -base & -gui, Nicola Pero, 2003/07/03
- Re: [RFC] Header organization of -base & -gui, David Ayers, 2003/07/03
- Re: [RFC] Header organization of -base & -gui, Nicola Pero, 2003/07/03
- Re: [RFC] Header organization of -base & -gui, Nicola Pero, 2003/07/03
- Re: [RFC] Header organization of -base & -gui, David Ayers, 2003/07/03
- Re: [RFC] Header organization of -base & -gui, Adam Fedor, 2003/07/03
- Re: [RFC] Header organization of -base & -gui, David Ayers, 2003/07/04
- Re: [RFC] Header organization of -base & -gui, Adam Fedor, 2003/07/06
- Re: [RFC] Header organization of -base & -gui, David Ayers, 2003/07/06
- Re: [RFC] Header organization of -base & -gui,
David Ayers <=
- Re: [RFC] Header organization of -base & -gui, Pete French, 2003/07/07
- Re: [RFC] Header organization of -base & -gui, Markus Hitter, 2003/07/08
- Re: [RFC] Header organization of -base & -gui, David Ayers, 2003/07/08
- Re: [RFC] Header organization of -base & -gui, Nicola Pero, 2003/07/08
- Re: [RFC] Header organization of -base & -gui, David Ayers, 2003/07/08
- Re: [RFC] Header organization of -base & -gui, Nicola Pero, 2003/07/09
- Re: [RFC] Header organization of -base & -gui, David Ayers, 2003/07/30
- Re: [RFC] Header organization of -base & -gui, Adam Fedor, 2003/07/08
- Re: [RFC] Header organization of -base & -gui, Alexander Malmberg, 2003/07/09
- Re: [RFC] Header organization of -base & -gui, Markus Hitter, 2003/07/03