[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FHS compliance for libraries (was Re: gnustep-make experiment)
From: |
Gregory John Casamento |
Subject: |
FHS compliance for libraries (was Re: gnustep-make experiment) |
Date: |
Sun, 28 Jan 2007 22:37:02 -0800 (PST) |
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
- FHS compliance for libraries (was Re: gnustep-make experiment),
Gregory John Casamento <=