Re: Please do not hardcode GNUSTEP_INSTALLATION_DOMAIN in GNUmakefiles!

[Nicola Pero]

> > > Question to Nicola; maybe gnustep-config should be in /usr/local/bin
> > > to successfully provide a bridge from standard Unix hierarchy to
> > > whatever layout the GNUstep installation is using? The -make package
> > > would then need two different --prefix options, which is a bit of a
> > > problem.
> >
> > Yes - we could have a ./configure option to specify where you want to
> > install gnustep-config, openapp and opentool.  If nothing is  
> > provided,
> > we'd default to install them into SYSTEM_TOOLS, like we do now. :-)
>
> Well, people expect to simply do ./configure; make; make install, and
> have everything work out of the box. As long as gnustep-config
> defaults to a Tools directory, the chicken-egg problem will persist;
> to find gnustep-config you need to know something that you run
> gnustep-config to reveal. I would think the whole point of this script
> was to be available in $PATH when the environment is not yet set up?

I see your point and  it's a very good one. :-)

Now in practice nobody seems to be having that problem though. ;-)

The problem that the average "Joe User" has is that they do ./ 
configure; make; make install
of all the GNUstep packages they need, and then they want to run some
application, and it doesn't run (alternatively, they install  
prepackaged GNUstep
packages or similar).  They try typing 'Gorm' and it doesn't start.   
Typically, they
ask for help, someone tells them to do

 . /usr/GNUstep/System/Library/Makefiles/GNUstep.sh

and things start to work.

Having gnustep-config in the PATH already, or not, wouldn't help.   
"Joe User"
will want to use GWorkspace or Gorm or some/many other
GNUstep applications.  These are the binaries that need to be in his
PATH for him to be happy.  And they are in LOCAL_TOOLS or
SYSTEM_TOOLS.

Which is why a GNUstep system is never really be usable unless
LOCAL_TOOLS and SYSTEM_TOOLS are in your PATH ... now if you
use FHS, they automatically are; if you use the GNUstep filesystem
layout, you need to add them manually to your PATH, or you need
to source GNUstep.sh. ;-)

Having 'gnustep-config' in your PATH doesn't help with any of these
tasks :-(

So the chicken-and-egg problem has to be solved by the user ...

 1. if they use the FHS layout, everything is automatically in their  
PATH,
including gnustep-config and all the applications.  This is the only
100% "Joe Unix User"-proof configuration where things work out of the  
box
automatically and Unixly ;-)

 2. if they use the GNUstep filesystem layout, they need to add  
SYSTEM_TOOLS
and LOCAL_TOOLS to their PATH manually, or add the line

 . /usr/GNUstep/System/Library/Makefiles/GNUstep.sh

to their /etc/profile or startup script.  Most "Joe User" kind of  
persons will
just source GNUstep.sh on startup (once they realize they have to do  
it).
And yes, they'd be hardcoding the path of their GNUstep installation  
in there.
I don't think that's a problem though - if they move their GNUstep  
installation,
they will change it. ;-)

If they had gnustep-config in their PATH, yes they could use

 . $(gnustep-config --variable=GNUSTEP_MAKEFILES)/GNUstep.sh

which is all good ... no hardcoded paths ... but from the point of  
view of Joe
User, it is even more mysteriously and unreasonably complicated.  ;-)

To be honest, to make everything work as easily as possible for Joe  
User,
we'd need to use FHS as the default layout.  Then everything is
just in their PATH from the very beginning and that's it.  But our  
policy is
to keep the GNUstep filesystem layout as the default layout; in which  
case,
everything is out of their PATH, and they do need to source GNUstep.sh
to do anything with GNUstep.  There's no other solution really ... and  
once
they have sourced GNUstep.sh, then gnustep-config is in their PATH even
if it's installed in the GNUstep filesystem.

Maybe we ought to print a quick explanation of the filesystem layout
they chose at the end of ./configure in gnustep-make; potentially with
suggestions for other layouts ?  That might really help new users.

Eg, we tell them to source GNUstep.sh at the end of ./configure
if they choose the GNUstep layout.


> Ideally, gnustep-config would install to /usr/local/bin +
> /usr/local/man and the domains to /usr/local/GNUstep. With ./configure
> --prefix=/usr, they would be /usr/bin, /usr/man, and /usr/GNUstep. I
> don't know how feasible this is as it would require changes to the FS
> layout system. The use of $prefix currently varies between layouts.
> With the gnustep one, the prefix option is on the form
> --prefix=/usr/GNUstep rather than the standard --prefix=/usr, while
> the apple layout assumes --prefix=/


Yes

Btw one bit I like about the GNUstep filesystem is that everything is  
installed into
/usr/GNUstep so you can delete/rename/replace your entire GNUstep  
installation
by just deleting/renaming/replacing that single directory (plus the  
config
file).  That is really nice. ;-)

I suppose installing a single tool (gnustep-config) outside of that is  
no big deal,
even if obviously breaks the concept ... and might go down a slippery  
path, ie,
why not also installing symlinks to Gorm and other applications in / 
usr/bin ?
But then you end up using the FHS filesystem layout ;-)

Anyway, I think having an option to install gnustep-config outside of  
the GNUstep
domains, and straight into some other directory which is "in the  
PATH", eg,
into /usr/local/bin, sounds good.  We could add a CONFIG_TOOLS which is
outside of the main domains (a bit like GNUSTEP_MAKEFILES).  I'm not  
sure about
changing the default from SYSTEM_TOOLS though; I hardly see any  
advantages
for anyone in practice, but it does break the GNUstep  filesystem  
layout idea that everything
but the config file is in there. :-/

Thanks