FHS compliance for libraries (was Re: gnustep-make experiment)

[Gregory John Casamento]

All,

Sorry to chime in so late on this one, RL has kept me quite busy over the last 
few weeks. :)

Wouldn't it be possible to change make so that it handles both setups (i.e. FHS 
or GNUstep)?    This way we could have one set of GNUmakefiles to handle 
everything, instead of two (as Nicola suggested).

I believe that all of the extra setup that is necessary to use the libraries 
outside of the FHS represents a "barrier to entry" to some users as they may 
not feel comfortable about using a set of libraries which requires them to make 
basic system level change to ld.conf.   It would be nice if there was an option 
to install the libraries in an FHS compliant manner to allow them to be used by 
GNUstep applications or, possibly, by other non-GNUstep programs.

Before anyone suggests it, I believe the value of splitting APPLICATION bundles 
into the FHS (the various resource dirs) is dubious at best and this debate 
will be left for another time.   For now we need to focus on making Libraries 
FHS compliant.

Thanks, GJC

--
Gregory Casamento

----- Original Message ----
From: Nicola Pero <address@hidden>
To: David Ayers <address@hidden>
Cc: Richard Frith-Macdonald <address@hidden>; address@hidden
Sent: Thursday, January 25, 2007 8:58:02 PM
Subject: Re: gnustep-make experiment


> Personally I'd prefer to suspend the release until we have an
> environment that has a chance of remaining stable.  It seems that we
> already require -make users to adapt thier projects for this release (I
> remeber you cleaning up many projects in SVN) and it seems they may need
> to adapt again for the subsequent release.

That's a good point to discuss, on the other hand sooner or later we need to
ship the changes so they start getting widespread.  I believe we have enough
changes to ship a new release!

The main changes in the new gnustep-make are:

 * libraries have now the same name no matter if you compile them with debug, 
porofile, static or what.  _d, _p, _dp etc. are gone.

 * applications have now the same name no matter if you compile them with debug 
or what.  Gorm.debug is gone.  Now it's only Gorm.app.

 * all object files are now put in ./obj.  shared_obj, shared_debug_obj, etc. 
are gone.

Those may require projects that contain custom makefile code to be updated!

The other main change is that using GNUSTEP_SYSTEM_ROOT, GNUSTEP_LOCAL_ROOT, 
etc. in makefiles is now discouraged (because it won't work with Linux FHS).  
This has no effect though, for now you can happily use them.  Also, the new 
release will work without sourcing GNUstep.sh, in which case you can't really 
use the GNUSTEP_SYSTEM_ROOT, etc. shell variables any more.  They are 
effectively obsolete.

Finally, the new gnustep-make supports GNUSTEP_INSTALLATION_DOMAIN and it's 
strongly recommended that this is used instead of GNUSTEP_INSTALLATION_DIR 
(GNUSTEP_INSTALLATION_DIR won't work with
Linux FHS).  You don't need to change it now, but over time we hope everyone 
will switch to GNUSTEP_INSTALLATION_DOMAIN

I suppose maybe you (and Helge) are right, we could wait a few more months and 
finish off all changes, then we ship a gnustep-make 2.0.0 so there is a single 
major upgrade. ;-)

It actually makes quite some sense, I'm tempted to do that now. :-)

Comments welcome

Thanks



_______________________________________________
Gnustep-dev mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnustep-dev