[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep.sh / env sanity patches

From: John Davidorff Pell
Subject: Re: GNUstep.sh / env sanity patches
Date: Thu, 19 Aug 2004 13:59:19 -0700

On 19 Aug 2004, at 03:33, Nicola Pero wrote:
By allowing for this, you are required to use hacks like this

That's not a hack.  That's a native configuration file describing the
GNUstep layout and setup on that machine.  You use that file to locate
where GNUstep is and how is setup on the machine.

You have some obsession with your idea of "native"...

If we do not support this bad idea, then most of its functionality can
be ditched as the libraries and tools can manage most of it (through
relative paths) and LD_LIBRARY_PATH and GNUSTEP_MAKEFILES take care of
the rest.

I don't think so.  How will gnustep-base find the location of the local
domain ?  It must be hardcoded somewhere, right ?  So why not in a
readable/editable text-file so you can both view what hardcoded value is in there, and even edit it if you want ? And here you have GNUsteprc. :-)

it should not be editable, if it is then it is begging for damage by a) stupid users b) stupid packagers

Also, hardcoded does not mean text-file. Maybe we are using two different meanings of the term. By hardcoded I mean that there is no place that it is derived from, the library already knows it. Does this make sense?

If the library knows where it is, or uses all relative paths, then there is NO need to GNUsteprc.

On a separate note: if you have multiple systems installed, then you
cannot have /etc/GNUsteprc because system 2 will overwrite system 1's
rc file. If you install it on /GNUstep1 then you should know to use

We already discussed this -- it will be supported, but you have to use a
configure switch if you are installing multiple systems to tell it to
place the GNUsteprc for each system somewhere else (in that system's root

:-/ The only people who want to be able to change the GNUstep installation directory after build is packagers who need to roll out an installation into a semi-arbitrary location. If the /user/ has to re-compile to install it in a different location, then this defeats your whole argument.


"The New York Times is read by the people who run the country. The Washington Post is read by the people who think they run the country. The National Enquirer is read by the people who think Elvis is alive and running the country ..."
-- Robert J Woodhead

Attachment: smime.p7s
Description: S/MIME cryptographic signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]