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

[Richard Frith-Macdonald]

On 16 Sep 2010, at 17:11, Quentin Mathé wrote:

> Hi Richard,
> 
> Le 16 sept. 2010 à 16:14, Richard Frith-Macdonald a écrit :
> 
>> On 16 Sep 2010, at 14:38, Wolfgang Lux wrote:
>> 
>>> Indeed you did. The problem is *not* an issue of the configure script, its 
>>> a runtime error which happens independent of the target OS whenever you 
>>> start an application or tool. (You would have noticed yourself if you had 
>>> added a GNUSTEP_FILESYSTEM_LAYOUT_FILE to your own GNUstep.conf). The 
>>> function ExtractValuesFromConfig in NSPathUtilities contains a sanity 
>>> check, which reports any nonstandard variable that is set in one of the 
>>> configuration files (and not listed in the GNUSTEP_EXTRA variable).
>>> 
>>> A quick workaround to get rid of the message is to add the line
>>> GNUSTEP_EXTRA=GNUSTEP_FILESYSTEM_LAYOUT_FILE
>>> to ~/.GNUstep.conf and the real fix is to add a line to discard the 
>>> GNUSTEP_FILESYSTEM_LAYOUT_FILE variable from the configuration dictionary 
>>> in ExtractValuesFromConfig.
>>> 
>>> Wolfgang
>>> 
>>> PS Can you please revert the change to make the apple layout the default on 
>>> Darwin systems when using the gnu-gnu-gnu combo. On OS X systems this 
>>> configuration is supposed to coexist with the existing Cocoa environment 
>>> and the apple-apple-apple combo, so these should clearly use separate 
>>> layouts. I also guess that the problem of fresh users attempting to install 
>>> GNUstep from source on OS X is not an issue here, since it won't work 
>>> anyway unless you are really experienced :-).
>> 
>> Thanks ... I've reverted a whole load of the changes.
>> 
>> NB. The net result is that temporarily you need to specify 
>> --with-layout=gnustep to get the gnustep layout ... until we can work out a 
>> good mechanism for setting a preference for the layout to use.
> 
> Shouldn't gnustep-make reuse the existing layout when there is already a 
> GNUstep install?

That was my original plan.

> If I do
> ./configure --prefix=/ --enable-debug-by-default --with-layout=gnustep && 
> make && sudo -E make install
> then
> ./configure --prefix=/ --enable-debug-by-default && make && sudo -E make 
> install
> 
> The second time, gnustep-make ignores my previous install and just reverts to 
> the fhs layout.
> I think it shouldn't switch the layout unless it's explicitly requested, and 
> each time the layout is changed, a warning should be displayed at the end of 
> the configuration to make things truly clear.
> Otherwise you can get weird results where some programs stop to compile 
> because gnustep-make still picks the old headers of the previous GNUstep 
> install. This happened to me when I update my working copy, because I usually 
> don't source GNUstep.sh when I reinstall gnustep-make unless I make a new 
> install in another location.

My first thought was that we should keep the existing layout unless it's 
explicitly changed, but Nicola made the reasonable point that doing that would 
mean that the results of running configure one time would be effected by 
previous runs and that this would make it harder to diagnose the cause of 
problems when someone reports difficulties configuring gnustep-make.  He also 
pointed out that gnustep-make has always ignored existing config and produced a 
new one using the instructions passed to it.

However, the idea of reporting differences from the previous config sounds like 
a good one.