On Wed 2012-04-11, at 12:03 PM, Alfred M. Szmidt <ams@...> wrote:
> It is simple enough to recompile a program, and there is little
> benefit in looking things up at run-time.
Position independence is generally a good idea. Position dependence is brittle.
Here’s an example: I have two versions of apache, the installed version, and the new version for testing. Once the new version is blessed, I move the installed version from the main installed location to /usr/local/apache-previous or suchlike, and move the staging version into the main installed location. I can still test on the old version for sanity checks by using it in its new location. Having to use make install again twice to make this work is waste and invites errors.
>> Thinking about this some more, being able to change the prefix with
>> minimal rebuilding is a feature that goes along with my proposal.
> `make install' doesn't rebuild anything in a already built directory;
> even if you set prefix during `make install' it will not rebuild (if
> it does, it is a bug in the package).
I don’t recall ever reading in configure documentation that prefix= works as an argument to make install
So I tried an experiment
Z% ./configure prefix=/usr/local/gcc-4.7.0
Z% make install
Z% make prefix=/home/yost/gcc-4.7.0 install
Z% find /home/yost/gcc-4.7.0 -type f | exec tr '\012' '\000' | xargs -0 "$@" strings | grep /usr/local/gcc-4.7.0 | wc
139 259 7642
Z% find gcc-4.7.0 -type f | exec tr '\012' '\000' | xargs -0 "$@" strings | grep /home/yost | wc
0 0 0
>> 1. I installed temporarily into /usr/local/gcc-4.7.0/ until we
>> decide that we are ready to cut over. Then I will install into
>> /usr/local/. It would be nice to be able to edit a file, say
>> “config-prefix”, then do a make install, and not have to wait
> `make install' is fairly quick; if it takes hours then you are doing
> something terribly wrong.
What does take quite a bit of time is running configure again with a different prefix. It was my understanding that you had to do this to change prefix.
>> 2. After doing the proposed “make binary-distribution”, someone who
>> receives the resulting pruned tree could edit the config-prefix
>> file and do a make install into their desired destination.
> As noted before, DESTDIR provides a more flexible mechanism; so such a
> target is essentially useless.
OK, that’s a perfectly good name for the feature.
>> Actually, I think the configure “prefix” feature should be
>> Software should be written to find everything it needs at runtime
>> relative to the path of the invoked binary.
> The problem with that is two fold, one it would require changing
> several hundred of thousands of programs.
That is not an argument against a better way of doing things.
> Second, it would be
> impossible to find system configuration files, libexec type programs,
> etc without a lot of complicated FOO_PATH and FOO_PROGRAM variables.
I don’t understand point two. Can you give an example?