GNUstep Package Re-org (Was: GNUstep download section)

[Jonathan Gapen]

Nicola Pero wrote:
> 
> > > How about some debs in addition to rpms? Or is no-one using
> > > Debian here?
> > >
> > I do.
> >
> 
> I do at home.
> 
> [...]

    Actually, this message reminds me of my own ideas for a
re-organization of the GNUstep packages, and it helped trigger a few
good refinements.  I agree that the current organization is a mess of
strange dependencies, like gnustep-make depending on many libraries.  I
propose the following for consideration:

    * Yet-Another-Package:  Create another, simple package that simply
sets up the GNUstep directory structure, and sets up config.site.  This
eliminates the chicken-and-egg problem of wanting to install libobjc,
special gcc, libtiff, and/or etc. in the GNUstep directory structure,
but needing to install gnustep-make first, which in turn needs these
things.  In the future, this package could act as a catch-all for steps
needed to prepare a system for GNUstep.
    * Turn gnustep-base and gnustep-gui into simple framework projects. 
Frameworks ought to have some way to inject the compiler flags they need
into the build process for a project.  This way, the GNUstep packages
wouldn't have to install *.make files with their options, gnustep-make
wouldn't have to hard-code a check for them, and it'd be a generalized
feature that applies to all projects.  That is, a project's GNUmakefile
could just say "FRAMEWORKS = base" and the rest is done automatically.
    * As a result of the above, weed out unrelated items from
gnustep-make, so it contains just a bunch of makefiles.

    After these changes, the dependency map would look like:

gnustep-prep -> nada!
gnustep-make -> gnustep-prep
gnustep-base -> gnustep-make, libobjc
gnustep-xgps -> gnustep-base, libtiff, libwraster, libpng, libjpeg, etc.
gnustep-gui  -> gnustep-base, gnustep-xgps, libtiff, libwraster

    How does that sound?

    Incedentally, is there any reason to have gnustep-xgps,
gnustep-xdps, etc. as seperate top-level projects?  As I understand it,
xgps' "DPS operators" are inline functions that really call cached ObjC
methods.  As such, gnustep-gui and gnustep-xgps are joined at the hip. 
Therefore, we'll need a different gnustep-gui package for each backend. 
It does make sense for GNUstep developers to maintain the backends as
seperate projects, but there's no point in having different packages for
the user to install.
    I would like to see a truly backend-oblivious gnustep-gui, so the
user could install multiple backends to use with the same gnustep-gui
library, but since that's unlikely, why not bundle 'em up as one?

-- 
All persons, living or dead, are purely coincedental.