Re: path handling changes to try out ...

[Nicola Pero]

> > You surely can, but it obviously can not apply to the program that was
> > just started, because that is only used when loading dynlibs at startup.
> > But it will apply to any child started from there on, by the app that
> > set LD_LIBRARY_PATH.
> 
> What about bundles loaded after the initial startup ? Will they use a 
> modified LD_LIBRARY_PATH ?
>
> Anyway, since it isn't really possible for an executable to 
> "autoconfigure", this might be the justification for the 
> executable.template in case of a missing setup ? (I think Nicola wanted 
> to remove support for that ..)

I've already removed it :-)

Seriously, it was totally useless, and it has nothing to do with the
current discussion.  To find the executable.template, which is deep inside
the gnustep directories, you must have already set up your PATH to look
into the gnustep directories, which means you have already sourced
GNUstep.sh.  Using executable.template for tools means running a shell
script (long and complex) each time you run a tool - which implies that
tools are extremely slow - nearly unusable if you need to write tools
which perform reasonably quickly.  Even if for you is not a problem, in
certain cases it is a very serious problem.

If you need to source GNUstep.sh before starting a tool, why not using the
following shell script -

#! /bin/sh

. /opt/gnustep/System/Makefiles/GNUstep.sh
mytool "$@"

just save this as /usr/bin/mytool and then you can execute mytool from the
command line perfectly well - without having to set up anything in
advance, not even the PATH.

But if you install the tool in the standard gnustep path (without this
script), then you have to set up the PATH otherwise the tool can't be
found, and if you have to do this, why not setting LD_LIBRARY_PATH as well
(/simply source GNUstep.sh) ?

If you don't want to set up LD_LIBRARY_PATH, please consider adding your
gnustep paths (system/local/network) to /etc/ld.so.conf, and running
ldconfig (but you need to do it after installing each library).  It's not
forbidden :-) it's actually recommended if you don't have multiple
library-combos.  It's even compulsory if you need setuid executables,
because setuid executables ignore completely LD_LIBRARY_PATH for obvious
security reasons.

I don't mind simplifying and improving gnustep-make startup and
configuration if the suggestions are good and workable ... the problem is
I don't see that much space for improvements, without loosing valuable
features.  If you have suggestions, let me/us know.