Re: Totally Gormless

[Nicola Pero]

> > 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)
> 
> If we're thinking of just sourcing the file in make, that's probably a 
> good idea. However, that was never the original intention. The 
> SYS/PLATFORM/PLATFORM_LOCAL paths are strictly for non-GNUstep tools, 
> so that a gnustep-base user could discover the location of a system 
> tool using GNUstep methods. They are not for use by gnustep-make at 
> all.

Ah - thanks - I see - I got it all wrong then ;-)

So the arbitrary 'relocation' of GNUstep tools/libraries/bundles/etc
(which is we've been wanting for ages) is not really implemented yet, is
it ? :-(

Eg, you can't put GNUstep tools in /usr/local/bin, frameworks and bundles
in /usr/local/share and expect that by changing something in GNUstep.conf,
they will be found by gnustep-base ?

OK - anyway, shouldn't be difficult to add at this point, I'll book that
task for me :-)

But I can't see much use for the SYS / PLATFORM / PLATFORM_LOCAL variables
then ... presumably you can access those eg SYS_APPS settings via the
standard OpenStep API to get paths ? ... they won't work on other OpenStep
systems though and the paths you get from the API calls aren't much use
unless you have code that deals differently with all the types of system
you can work on ... eg, once I'm told that SYS_APPS is //C/Windows (is
that the location of system binaries in Windows ?), I need to have heavily
platform-dependent code to know what to do with that path, eg which
executables I can find in that path!  At which point the benefit of having
the API giving you SYS_APPS is lost, isn't it ?

Maybe someone has got a good example of how those are used ?

Personally I'd vote for removing SYS_APPS etc. entirely from the API.

If we keep them, that's fine, but maybe can we move them into a separate
config file used only by gnustep-base ?  So when I include GNUstep.conf in
gnustep-make I don't get those variables.  I suppose we could still be OK
with them, but it's just cleaner not to pollute the shell/makefile
namespace with SYS_APPS etc.


> > 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 :-(
> 
> Well yes, but the original intention of the GNUstep.conf file was to 
> be able to fully specify the locations of important files so you 
> wouldn't have to rely on gnustep-make. i.e. gnustep-base could be 
> distributed and used without gnustep-make.

That's a very good objective, and I fully support it :-)

... but obviously syncing the way that gnustep-base and gnustep-make
determine paths would bring benefits and open the doors for further
advancements ;-)

I'm particularly inclined to do the native Unix path support (eg,
/usr/bin) and maybe look at Windows installers ... those obviously need
gnustep-make and gnustep-base to agree on paths ... even if gnustep-base /
the tools / apps at runtime will be running without gnustep-make, when you
build and install and package and develop obviously gnustep-make needs to
know where to find and put things ;-)

(and I need to finish looking at Windows frameworks -- will do that too)

Thanks