[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] Header organization of -base & -gui
From: |
Nicola Pero |
Subject: |
Re: [RFC] Header organization of -base & -gui |
Date: |
Tue, 8 Jul 2003 13:27:46 +0100 (BST) |
My personal feeling is that the best organization would be the following:
* with library-combos (non-flattened gnustep) enabled:
Headers/gnu-gnu-gnu/Foundation/
Headers/gnu-gnu-gnu/GNUstepBase/
Headers/gnu-gnu-gnu/AppKit/
Headers/gnu-gnu-gnu/GNUstepGUI/
Headers/gnu-gnu-gnu/Renaissance/
Headers/gnu-gnu-gnu/AnyLibrary/
Headers/gnugc-gnu-gnu/Foundation/
Headers/gnugc-gnu-gnu/GNUstepBase/
Headers/gnugc-gnu-gnu/AppKit/
Headers/gnugc-gnu-gnu/GNUstepGUI/
Headers/gnugc-gnu-gnu/Renaissance/
Headers/gnugc-gnu-gnu/AnyLibrary/
Headers/apple-apple-apple/GNUstepBase/
Headers/apple-apple-apple/GNUstepGUI/
Headers/apple-apple-apple/AnyLibrary/
Headers/gnu-fd-nil/Foundation/
Headers/gnu-fd-nil/AnyLibrary/
On the command line, the single flag -Ixxx/Headers/$LIBRARY_COMBO is used.
Please note that -Ixxx/Headers/ is *not* passed on the command line.
With library-combos, you can have support for multiple library-combos on
the same GNUstep installation.
That means for example that you can compile, run, install both
apple-apple-apple (that is, Apple OSX native) and gnu-gnu-gnu (GNUstep
native) and apple-gnu-gnu (GNUstep built on top of Apple runtime) and
apple-fd-nil (libFoundation built on top of Apple runtime) and
gnugc-gnu-gnu (GNUstep built on GNU with garbage collection)
applications / libraries / frameworks in the same GNUstep installation on
Mac OS X, and they would share the same directory layout.
I very much like using library-combos (such as 'gnu-gnu-gnu') instead of
`gnustep' as header directories because they make clear, at least to an
advanced user, what we are talking about. They are consistent with the
names/directories we use for object files. People who don't need
library-combos (most of them) can just --enable-flattened in
gnustep-make's ./configure and forget about them. People who need
library-combos have a single unified way of organizing headers and
libraries and frameworks and applications. It will also help future
changes (such as simplification or advancements of library-combo support)
to be made consistently and simply on all areas.
* with library-combos disabled:
[Headers/Foundation/]
Headers/GNUstepBase/
[Headers/AppKit/]
Headers/GNUstepGUI/
Headers/Renaissance/
Headers/AnyLibrary/
On the command line, only -Ixxx/Headers/ is used.
-Ixxx/Headers/gnu-gnu-gnu/ is *not* passed on the command line.
In this mode, library-combos are disabled. You have a single
library-combo system.
==
The existing options (--enable-flattened and --enable-multi-platform) in
gnustep-make's ./configure should be enough to support this.
Maybe we could change the default as Adam seems to suggest, and make the
default --disable-flattened and --disable-multi-platform.
That seems still open to discussion. Opinions on that ?
> 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.)
--enable-multi-platform as it is now has nothing to do with using gc and
non-gc versions of gnustep at the same time; I assume you are talking of
a future proposed implementation.
Still I'd like to point out that at the moment, even if you use
--disable-multi-platform (which is the default), you can still use
library-combos.
You can use
export LIBRARY_COMBO=gnugc-gnu-gnu
. /usr/GNUstep/System/Library/Makefiles/GNUstep.sh
to start up a gnugc-gnu-gnu environment. And you can use
. /usr/GNUstep/System/Library/Makefiles/GNUstep-reset.sh
export LIBRARY_COMBO=gnu-gnu-gnu
. /usr/GNUstep/System/Library/Makefiles/GNUstep.sh
to switch back to your gnu-gnu-gnu environment.
--enable-multi-platform has no influence on this at the moment.
> 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.
Yes. I wouldn't be much afraid of this change.
- Re: [RFC] Header organization of -base & -gui, (continued)
- 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, 2003/07/07
- 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 <=
- 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
- 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, David Ayers, 2003/07/01
Re: [RFC] Header organization of -base & -gui, David Ayers, 2003/07/01