gnustep-dev
[Top][All Lists]
Advanced

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

Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.


From: Nicola Pero
Subject: Re: [Gnustep-cvs] r31321 - in /tools/make/trunk: ChangeLog GNUstep.conf.in configure configure.ac
Date: Mon, 20 Sep 2010 18:28:37 +0200 (CEST)

>>  * if installing into /usr/local/, install GNUstep.conf into 
>> /usr/local/etc/GNUstep/GNUstep.conf
>>    instead of /etc/GNUstep/GNUstep.conf
>
> Why only in this case? We could make it the default on all systems (but
> my OpenSuse 11.3 doesn't have this directory by default) or find a
> better conditions for this.

Well, if you install into /usr (as we do now), the config file should go into 
/etc/GNUstep/GNUstep.conf, 
where it is now (as prescribed by the fhs and by normal Unix conventions). :-)

It only needs to go into /usr/local/ if you are installing everything into 
/usr/local/ ;-)


>>  * add a --remember-prefix-and-layout and --forget-prefix-and-layout options 
>> to configure (or similar)
>>    that will enable remembering the prefix and layout across configure 
>> invocations.  This will be
>>    disabled by default as it would confuse new users (and we're picking all 
>> the default options to
>>    be best for new users).
>
> This is a very important part of the setup. It is not just that I am to
> lazy type the file system layout selection each time I install GNUstep
> make, which is at least after every change to that package.

Yes.  I think the --remember-prefix-and-layout option would be used by people
like you and me who rebuild gnustep a few times per day and would otherwise 
have to type --with-layout=gnustep every time they configure gnustep-make ;-)

But I wouldn't make it the default.

The reason is that we are making changes to make GNUstep more "standard" for 
the average
Unix user.  And standard configure scripts don't magically pull out 
installation directories
by looking at a similar package already installed somewhere on the machine.  
That would
be confusing for the average new "Unix" user who expects configure to obey the 
flags that it
is passed and nothing else.

No matter what they are doing, they would not expect that behaviour, and would 
be very annoyed
when they discover that configure is behaving in some different, unusual and 
surprising way
(no matter how clever it is).

We can have a configure option to turn special behaviour on for our own 
pleasure, but I
wouldn't push it onto the average user. ;-)

Thanks




reply via email to

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