[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnustep-make experiment
From: |
Nicola Pero |
Subject: |
Re: gnustep-make experiment |
Date: |
Thu, 25 Jan 2007 01:14:47 +0100 (CET) |
> 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
- RE: gnustep-make experiment, (continued)
RE: gnustep-make experiment, Nicola Pero, 2007/01/24
Re: gnustep-make experiment, Nicola Pero, 2007/01/24
RE: gnustep-make experiment, Nicola Pero, 2007/01/24
Re: gnustep-make experiment,
Nicola Pero <=
Re: gnustep-make experiment, Nicola Pero, 2007/01/25
Re: gnustep-make experiment, Nicola Pero, 2007/01/25
Re: gnustep-make experiment, Nicola Pero, 2007/01/25
Re: gnustep-make experiment, Nicola Pero, 2007/01/25