Hmph. That's reverting this:
commit 4c5cf8c44ce06a79da5bafd4a92e6d6f598cea2e
Author: Eric Wong [off-list ref]
Date: Sun Aug 13 04:13:25 2006 -0700
pass DESTDIR to the generated perl/Makefile
Makes life for binary packagers easier, as the Perl modules will
be installed inside DESTDIR.
Signed-off-by: Eric Wong [off-list ref]
Signed-off-by: Junio C Hamano [off-list ref]
Eric, care to comment?
Junio C Hamano [off-list ref] wrote:
Hmph. That's reverting this:
commit 4c5cf8c44ce06a79da5bafd4a92e6d6f598cea2e
Author: Eric Wong [off-list ref]
Date: Sun Aug 13 04:13:25 2006 -0700
pass DESTDIR to the generated perl/Makefile
Makes life for binary packagers easier, as the Perl modules will
be installed inside DESTDIR.
Signed-off-by: Eric Wong [off-list ref]
Signed-off-by: Junio C Hamano [off-list ref]
Eric, care to comment?
I used to make a statically linked binary package for working on an
ancient box that didn't have a lot of libraries I wanted, and I probably
just called `make install' into DESTDIR as a single step without calling
`make' alone without DESTDIR argument, or I had DESTDIR set in
config.mak
--
Eric Wong
On Wed, Dec 12, 2007 at 06:01:48PM +0000, Eric Wong wrote:
Junio C Hamano [off-list ref] wrote:
quoted
Hmph. That's reverting this:
commit 4c5cf8c44ce06a79da5bafd4a92e6d6f598cea2e
Author: Eric Wong [off-list ref]
Date: Sun Aug 13 04:13:25 2006 -0700
pass DESTDIR to the generated perl/Makefile
Makes life for binary packagers easier, as the Perl modules will
be installed inside DESTDIR.
Signed-off-by: Eric Wong [off-list ref]
Signed-off-by: Junio C Hamano [off-list ref]
Eric, care to comment?
I used to make a statically linked binary package for working on an
ancient box that didn't have a lot of libraries I wanted, and I probably
just called `make install' into DESTDIR as a single step without calling
`make' alone without DESTDIR argument, or I had DESTDIR set in
config.mak
Actually this fact generated a bug in debian packaging because git is
built then installed twice in different DESTDIRS, then parts of the
install is pruned (the two installs are arch-dependant and
arch-independant files install so it's a very good reason in term of
packaging).
The fact that perl.mak caches the DESTDIR make it install things in
the wrong place because it doesn't honour make DESTDIR=foo install and
always use the cached value instead, which is wrong.
I think Gerrit won't care if it's cached or not, he just cares that it
still honours environment if present.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
On Wed, Dec 12, 2007 at 09:02:11PM +0100, Pierre Habouzit wrote:
On Wed, Dec 12, 2007 at 06:01:48PM +0000, Eric Wong wrote:
quoted
Junio C Hamano [off-list ref] wrote:
quoted
Hmph. That's reverting this:
commit 4c5cf8c44ce06a79da5bafd4a92e6d6f598cea2e
quoted
quoted
Eric, care to comment?
I used to make a statically linked binary package for working on an
ancient box that didn't have a lot of libraries I wanted, and I probably
just called `make install' into DESTDIR as a single step without calling
`make' alone without DESTDIR argument, or I had DESTDIR set in
config.mak
Actually this fact generated a bug in debian packaging because git is
built then installed twice in different DESTDIRS, then parts of the
install is pruned (the two installs are arch-dependant and
arch-independant files install so it's a very good reason in term of
packaging).
The fact that perl.mak caches the DESTDIR make it install things in
the wrong place because it doesn't honour make DESTDIR=foo install and
always use the cached value instead, which is wrong.
I think Gerrit won't care if it's cached or not, he just cares that it
still honours environment if present.
Yes, precisely. Thanks, Gerrit.