> > PS: My original idea was to simply include GNUstep.conf in shell scripts. > > I > > hope the idea has been kept in the sense that the GNUstep.conf syntax is > > compatible with sh syntax. If so, and if we can just include GNUstep.conf > > in shell scripts (and makefiles!) instead of running C tools, that would > > be as fast and simple as you can get it. :-) > > Definitely -- as long as the other variables in that file like > "SYS_APPS" and all that don't start to pollute a user's environment. > No reason they would have to, of course, if that file gets source > while launching apps, not at a user login, like GNUstep.conf.
OK - I had a quick look and I'm really impressed by all the advances in gnustep-base with respect to paths! Excellent job guys :-) But ... when I looked at the names and started to think how to integrate with gnustep-make my hair went straight up ;-) I'd say that -- Variable names those should be GNUSTEP_SYS_APPS, not just SYS_APPS ... so that we properly use a GNUSTEP_* namespace for all our GNUstep variables! (key requirement if we want to be able to just include GNUstep.conf in shell scripts and makefiles) Also -- maybe it should be GNUSTEP_SYSTEM_APPS, not GNUSTEP_SYS_APPS ? I'm also a bit unsure about the name 'APPS' ... it seems to be referring to stuff like /bin ... where we usually install tools, not apps. Not sure where an .app would go ... presumably into GNUSTEP_PLATFORM_RESOURCES ? Shall we maybe let the user choose where they want apps to go, and if they want them to go in the same directory as tools or not ? So we could presumably have GNUSTEP_SYSTEM_APPS, GNUSTEP_SYSTEM_TOOLS etc. but we make sure there is a simple subset (maybe 3 or 4) defaults that need to be set, everything else would be deduced by those (unless optionally, special settings for those are used). Btw, how did we choose the names 'SYS' / 'PLATFORM' / 'PLATFORM_LOCAL' btw? It looks like the 'SYS' is missing the resource directory, which is essential to us (isn't it ? bundles / apps / frameworks will go in there). Also, 'SYS' seems to map to where usually the core Unix stuff is installed -- and where we won't install anything! Presumably we actually want to have SYSTEM --> /usr/, LOCAL --> /usr/local/, and leave / alone ? Except for maybe /etc/GNUstep that would map to some GNUstep system preferences directory ? In other words, can we reduce SYS/PLATFORM/PLATFORM_LOCAL to just SYSTEM/LOCAL where by default we (roughly, to give an idea) map SYSTEM subdirs --> /usr/ subdirs and LOCAL subdirs --> /usr/local/ subdirs ? Otherwise, the mapping between SYSTEM/LOCAL used by gnustep-make and SYS/PLATFORM/PLATFORM_LOCAL would become even more complicated and confusing that what it is already going to be. ;-) Also, I'd rename USER_GNUSTEP_DIR into GNUSTEP_USER_DIR for consistency ... everything should start with GNUSTEP_* Btw, why USER_GNUSTEP_DEFAULTS and GNUSTEP_DEFAULTS_ROOT work in totally different way ? Can we unify and have a single logic behind those variables ? It looks like gnustep-make has no integration with this at all :-( Anyway, I'm willing to do work on integrating this with gnustep-make (also checking what OpenGroupware.org is doing to make sure we cover their needs and maybe finally they can leave their gnustep-make's fork), but if I do I'm going to rename most variables and reorganize much of this -- probably breaking backwards compatibility quite hard if anyone is using the file already (that I very much doubt given gnustep-make doesn't support it at all). I doubt we can easily merge with gnustep-make unless we rationalize the logic behind and try to merge it with the existing logic used in gnustep-make. :-) Any special comments ? (please no flamewars though, be polite thanks) > > I seem to remember there is lot of hidden complexity in here, but > > don't > > remember much about the details, so probably reading old email > > archives and > > checking what the code does etc. is required! ;-) > > I spent an evening with post-its and NSPathUtilities.m when 1.11.0 > make/base were released trying to reconstruct my $HOME-respectng > patch, trying to flow-diagram the different paths through the code. I > feel the only part that makes the code scary is compatibility support > for GNUsteprc ... Also, I feel like there were many sections of dead > code because of this; hopefully that will be removed when backwards > compatible support for GNUsteprc is removed. Yes, I'm for scrapping the old code. We've got enough messy complications in the new one ;-) > However, I think it was about last year this time when I submitted > similar patches against an older -base, and they were rejected, iirc, > because some were afraid of what would happen if someone used "su" ... That might actually be a good argument. :-( (I haven't looked at the patches though) > Another reason for the patch is that I also need it for allowing > builds to complete while in a sandbox (i.e. Gentoo ebuilds). The > simple act of making or installing apps, and docs, would create > ~/GNUstep in /root. Thanks - this is certainly an interesting problem :-) I would have imagined the new configuration system would give you enough power to redirect the root's user directory / defaults to /tmp/xxx ... ;-) ... maybe not ? Thanks _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
