discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Please do not hardcode GNUSTEP_INSTALLATION_DOMAIN in GNUmakefiles!


From: Nicola Pero
Subject: Re: Please do not hardcode GNUSTEP_INSTALLATION_DOMAIN in GNUmakefiles!
Date: Wed, 29 Oct 2008 13:16:48 +0000

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]