[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Upcoming releases
From: |
Nicola Pero |
Subject: |
Re: Upcoming releases |
Date: |
Tue, 29 Jul 2003 10:41:45 +0100 (BST) |
> >>I hope to make the next unstable release(s) of the core libraries,
> >>probably starting Tuesday night.
> >>
> >>
> >Let us know when it would be the right time to make the header
> >installation dir updates.
> >
> >It seems it would be the last major filesystem layout change, so I'd like
> >to get that in soon and then we can keep the filesystem layout we have
> >unchanged forever :-)
> >
> >
> I'm still ready to do the work, but Tuesday is a bit tight for me.
> Besides, we still have to decide on [...]
I'd like to do this change now, in the timeslot between this release and
the next one, as recommended by Adam.
As far as I am aware, we have reached a complete decision already (except
for some details).
The main enhancements we are trying to implement are:
- better support for multiple library-combos when library-combos are
used. Ideally I'd like a developer to be able to use Apple FoundationKit,
gnustep-base and gnustep-base with GC and libFoundation all at the same
time on the same system. At the moment it doesn't really work well with
headers.
- smaller compiler command-line reducing the number of -Ixxx options
passed to the compiler. That speeds up compilation and makes everything
easier to understand.
- easier transition between GNUstep libraries and Apple frameworks:
simplifying compiling gnustep-base-additions as a framework on Apple and
making possible to write code which can #include gnustep-base-additions
headers in such a way that it works no matter if gnustep-base-additions is
a GNUstep library or an Apple framework.
The main downside of the proposed change is:
- slightly increased number of top-level directories in Headers/. In
practice, all directories which were previously in Headers/gnustep/ now
would be top-level in Headers/. That probably adds around 10 new
top-level directories for a full install with quite a lot of non-essential
stuff. I don't see a way to avoid this unless we compromise the
enhancements we're trying to achieve; what we can do is to try to reduce
the problem by rationalizing header installation (not installing private
headers, and other rationalization such as putting all gnustep-base
headers either in Foundation/ or in GNUstepBase/, so unicode/ would *not*
be a top-level directory, but inside one of those two), and keeping in
mind that stuff which will never be used as a framework (such as gnustep
backends) does not need to be all top-level: all gnustep backend headers,
when installed, might be in GNUstepBack/{backend-name}/ rather than having
separate top-level dirs for each backend. Using those things together
would already reduce clutter considerably.
The proposed steps are:
1. make --enable-flattened the default (done!)
2. if library-combos are used, modify gnustep-make to install all headers
in Headers/$LIBRARY_COMBO/ rather than Headers/, and look for headers
there. (leaving -Ixxx/gnustep/ in place for the moment being).
3. modify gnustep-base and gnustep-gui to install headers in:
{header dir chosen by gnustep-make}/Foundation/
{header dir chosen by gnustep-make}/GNUstepBase/
{header dir chosen by gnustep-make}/AppKit/
{header dir chosen by gnustep-make}/GNUstepGUI/
the reason why those libraries are to be done first is that they
compose the library-combo - having them in library-combo keyed
directories when library-combos are used is one of our targets.
If you want to rearrange the headers inside the gnustep-base
source tree itself, this would be a good occasion.
Update all callers/users of gnustep-base-additions to include
headers using #include <GNUstepBase/Xxx.h>.
4. modify other core libraries to not rely on gnustep-make providing
a -Ixxx/gnustep/ flag automatically.
The very quick fix is just to modify the libraries to install headers
in {header dir}/{name} rather than {header dir}/gnustep/{name}.
That might be enough for some of the core libraries; but in general,
it might be a good occasion to update names too, switching from a
short-name form ("guile", "java", "x11", "xlib") to a long-name form
("GNUstepGuile", "GNUstepJava", "GNUstepBack/X11",
"GNUstepBack/XLib"), installing headers in {Headers}/{LongName}/
rather than {Headers}/gnustep/{short-name}, and updating all
#includes.
5. Remove the -Ixxx/gnustep flag from gnustep-make.
I'm now starting to work on 2; you could give a try at 3 if you like.
- Upcoming releases, Adam Fedor, 2003/07/20
- Re: Upcoming releases, Gregory John Casamento, 2003/07/20
- Re: Upcoming releases, Nicola Pero, 2003/07/21
- Re: Upcoming releases, Alexander Malmberg, 2003/07/29
- Re: Upcoming releases, Nicola Pero, 2003/07/29
- Re: Upcoming releases, David Ayers, 2003/07/29
- Re: Upcoming releases, Nicola Pero, 2003/07/29