[Top][All Lists]

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

Re: Feature request: setting env vars for binary wrappers

From: Behdad Esfahbod
Subject: Re: Feature request: setting env vars for binary wrappers
Date: Thu, 17 Apr 2008 18:05:44 -0400

On Fri, 2008-04-18 at 00:45 +0300, Roumen Petrov wrote:
> Behdad Esfahbod wrote:
> > On Thu, 2008-04-17 at 23:38 +0300, Roumen Petrov wrote:
> >>
> >> I think that all above is out of libtool scope.
> >> It's is exceptional project specific (lets skip cross-compilation 
> >> environment) and is subject of project regression test suite.
> >> The project is responsible to set appropriate test environment
> before
> >> to run regression test.
> >> Please let me know when I don't understand request properly.
> > 
> > It's not about regression testing at all.  It's about making
> binaries in
> > uninstalled builds work.  For example, many GNOME applications need
> to
> > load their UI from XML files.  If you build and not install them and
> try
> > to run from the build dir, not surprisingly, the XML file is not
> found
> > at destination, and the program will fail to start.  With my
> proposed
> > additions, programs can for example check for an env var for an
> > alternative prefix, and the Makefile.am can pass that information to
> > libtool to put into the wrapper.  Then running from uninstalled
> build
> > will work.
> > 
> > If running uninstalled build is not a goal, why bother about
> > LD_LIBRARY_PATH'ing the uninstalled library path at all?
> > 
> >> Roumen
> > 
> > Cheers,
> Exactly, libtool do home work and set LD_LIBRARY_PATH
> , LIBRARY_PATH, PATH and etc. host/platform specific environment
> library 
> search paths) but for application specific environment is
> author/project 
> responsibility. I see that you understand case when a library isn't 
> installed at specified(system) location. This library will load 
> dependent libraries from default(system) library search path. So the 
> wrapper script help correct library to be loaded so the libtool home 
> work is done.

Sure.  The request is: "since libtool already has this machinery for a
wrapper in place, can you please expose it to application developers so
they can benefit from it too?".

> But if user run directly an application installed in non-default 
> location the user is responsible to set environment.

I'm not talking about application installed in non-default location.
I'm talking about uninstalled application.

> If its a regression/unit test the correct application environment has
> to 
> be set in Makefile{|.in|.am} and the program/library will inherit it.

No, it's not a test suite.  It's a real, legitimate application the user
has built.  Now he wants to run it before doing "make install".

> Roumen

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759

reply via email to

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