> 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 _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev