>>>>> "Bernard" == Bernard Dautrevaux <[EMAIL PROTECTED]> writes:
>> The reason why you can't depend upon this is that somewhere, IMHO,
>> it is just wrong to expect make prefix=/foo to work properly.
>> Specifying prefix etc. is a job for configure, not make.
Bernard> You should be more precise; I agree that "make all
Bernard> prefix=/foo" may not work as expected; however "make install
Bernard> prefix=/foo" MUST work as expected, i.e. install in /foo
Bernard> something that to be executed should be "moved" in /usr/local
Bernard> or whatever the prefix was set by ./configure.
Well, I think this is a misunderstanding. My feeling was that the
expected behavior from
make install prefix=/foo
should be to recompile properly so that the executable be usable. I
claimed this was not sane, and you could not expect this from the
package maintainer.
So I was asking if the behavior of make install prefix=/foo be
comparable to that of make install DESTDIR=/bar. Thomas kindly
explained to me that these were two completely different things.
Now that I know what is the intention, it seems sane to me. Never lie
to ./configure on the location where things will be when used. Do
whatever you want on how you reach the `installed' state.
I'd like to ask it again though: what is the advantage (with this
interpretation in mind: just moving the package elsewhere) of using
prefix over DESTDIR?
The example you gave seems to be easy to address with DESTDIR. What
if a package has a dir which is not $prefix'ed?