Re: gnustep-make experiment

[Nicola Pero]

> so the idea was we replace all the environment variables with that we 
> install gnustep.pc by default into somewhere pkg-config will find it, then 
> people who want non-standard stuff fiddle with it can set PKG_CONFIG_PATH
> but it should just work by default

I'm a bit confused ... it looks like you are trying to solve some issues that 
have
already been solved! ;-)

I think I need to write more documentation on the new gnustep-make code, as it's
considerably more advanced than what we had before, but nobody seems to know 
much
about it. ;-)

The current implementation works as follows:

 * you configure your GNUstep paths by editing /etc/GNUstep.conf.  You can 
change them at any time by just editing the file

 * if you have multiple GNUstep installations, you should keep multiple conf 
files; you can specify that you want another config file to be used by setting 
GNUSTEP_CONFIG_FILE (or GNUSTEP_USER_CONFIG_FILE)

 * everything (both gnustep-make and gnustep-base) is getting the paths from 
the config files

 * everything executes once libraries are in the library paths and tools are in 
path

 * to compile, you only need to set GNUSTEP_MAKEFILES.

GNUstep.sh is still required/handy for more complex scenarios, for example when 
you have fat binaries.  You can still use it, keeping in mind it gets the paths 
from the config file now!  We want to keep it for backwards compatibility 
anyway.

Unfortunately, because all GNUmakefiles in the world start with the line

 include $(GNUSTEP_MAKEFILES)/common.make

and we want to maintain backwards-compatibility as much as possible (ie, we 
don't want everyone in the world to have to modify their GNUmakefiles, or 
worse, to have two copies of each of them for different gnustep-make 
versions!), GNUSTEP_MAKEFILES has to be defined to compile.  But we managed to 
make that variable the only requirement! :-)

Our plan is that Linux FHS support will also be somewhat backward compatible.  
GNUstep.conf will be extended with more variables, and gnustep-make and 
gnustep-base will automatically get them all from there and use them.

Once Linux FHS support is in place, stuff like GNUSTEP_SYSTEM_ROOT no longer 
has a useful meaning if you're using Linux FHS.  You should not use it.  All 
access to the filesystem should go through the OpenStep Foundation API (for 
ObjC code) or via gnustep-make public APIs/variables (eg, GNUSTEP_LIBRARIES); 
they will automatically take care of the local filesystem setup.

I guess you have a point that the gnustep-make ones are not entirely defined 
yet; they would be clearly defined once we implement Linux FHS.

I understand we might be missing some gnustep-make public APIs/variables/macros 
to locate things.  In that case, we can add them.  I don't agree with being 
able to get GNUSTEP_SYSTEM_ROOT though.  That variable will no longer have a 
well-defined/useful meaning in the new world.  It will be obsolete! ;-)

Old software that is installed in the old way (in a GNUstep filesystem) and 
sources the old GNUstep.sh will still have that variable available and will 
keep working; but if you want the old software to work in a new context (eg, 
Linux FHS), you have to move away from that.  Once you can freely configure 
gnustep-make to relocate system/local tools/bundles/apps/libs anywhere on the 
fileystem, then what does GNUSTEP_SYSTEM_ROOT mean / why would it be useful ?  
;-)

Thanks