autoconf
[Top][All Lists]
Advanced

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

Re: differences running in build dir or install dir


From: Brian Dessent
Subject: Re: differences running in build dir or install dir
Date: Wed, 14 Nov 2007 09:37:57 -0800

Bob Rossi wrote:

> This is a sort of general purpose question. It's typical that the
> build directory and the install directly have a different
> directory hierarchy. Therefor, if you run a built program in the
> build directory versus in the install directory, it would require the
> built program to look for files in different locations. My question is,
> is it typical to encode into the program a bit that tells it if it's
> being run in the build or install directory? Is it typically to say,
> "Only run the program from the install directory?" The second response
> would be to bad, considering the make install rule can be just an
> extra step in the development cycle, thereby wasting more precious time.

I guess it just really depends on what exactly is involved when you say
"look for files in different locations", i.e. what kind of files.

If you're using libtool, a wrapper is created for each program in the
build dir.  This allows uninstalled libraries to be used as if they were
installed, without having to relink or fuss with LD_LIBRARY_PATH.  And
most packages that have a testsuite take care to set up the test
environment (typically through some combination of program switches,
environment variables, or configuration files) so that the programs
being run in the build dir look for their associated files in-tree
instead of in the configured location.

I would wager that for the remaining use cases, either a) the program is
not complicated enough to require anything else (e.g. you can simply run
'ls' from the coreutils build dir and it will work fine) or b) running
the program in the build dir will use the installed copy of e.g.
configuration files in the specified $sysconfdir.  This makes a certain
amount of sense -- at least for those cases where the program is
complicated enough to require a valid config file -- since it implies
that the only interesting way to test the program is with a valid
configuration already set up, so if there's not some existing valid
config in the installed location then it's pretty meaningless to invoke
it.  (And, anyway, if it did provide a means of running a testsuite
that's insulated from any existing installed config, then it would
provide or generate such a configuration file in-tree which would be
specified through environment variables or program switches when running
"make check".)

Brian




reply via email to

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