Re: Totally Gormless

[Nicola Pero]

> > 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