GNU bug report logs - #7562
automake-set variables don't get properly reordered when overriden in Makefile.am

Previous Next

To reply to this bug, email your comments to 7562 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: bug-automake <at> gnu.org
Subject: automake-set variables don't get properly reordered when overriden in
	Makefile.am
Date: Sun, 5 Dec 2010 18:34:33 +0100

[Message part 1 (text/plain, inline)]

Severity: wishlist

This issue was brought up by Ralf Wildenhues in a thread on automake-patches.

Automake generally orders all of its variable settings before all of the user
ones (so the user ones are preferred).  But when one overrides e.g. bindir in
a Makefile.am, that variable doesn't get reordered to the user part, because
it is actually automake-set before it is overridden.  The issue is exposed in
the attached testcase.

It's still not clear to me whether this is a bug or a feature, but I thought
that entering it into the Automake bug database would be a good idea anyway.

Regards,
   Stefano

[automake-variable-reordering.test (text/plain, inline)]

#! /bin/sh

# Test that := definitions work as expected at make time, even when
# whey involve user-overridden automake-set variables.
#
# Currently, this test doesn't work, because automake generally orders
# all of its variable settings (e.g. bindir and the like) before all
# of the user ones.  Even when  bindir is overridden, it doesn't get
# reordered to the user part.  Might this be considered an automake bug?

required=GNUmake
. ./defs || Exit 1

set -e

cat >> configure.in << 'END'
AC_OUTPUT
END

cat > Makefile.am << 'END'
BAR := $(bindir)
BAZ = $(bindir)
bindir = foo
.PHONY: test
test:
	test x'$(bindir)' = x'foo'
	test x'$(BAZ)' = x'foo'
	test x'$(BAR)' = x
END

$ACLOCAL
$AUTOCONF
$AUTOMAKE -Wno-portability

./configure
$MAKE test

:

Message #8 received at 7562 <at> debbugs.gnu.org (full text, mbox):

From: Jack Kelly <jack <at> jackkelly.name>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 7562 <at> debbugs.gnu.org
Subject: Re: bug#7562: automake-set variables don't get properly reordered
	when overriden in Makefile.am
Date: Mon, 6 Dec 2010 07:28:04 +1100

Remark: This may be unrelated.

I don't know about overriding in Makefile.am, but overriding $(prefix)
is important for supporting GNU Stow. To set up a package for Stow,
you configure for one prefix and install under another (note that this
isn't the same as using $(DESTDIR) - that dumps the whole directory
tree under the target path).

Example:

./configure --prefix=$HOME
make
make prefix=$HOME/stow/foo-x.y.z
cd $HOME/stow
stow foo-x.y.z

So whatever you do with the variable ordering, I hope it doesn't break
overrides from the command line.

-- Jack

On Mon, Dec 6, 2010 at 4:34 AM, Stefano Lattarini
<stefano.lattarini <at> gmail.com> wrote:
> Severity: wishlist
>
> This issue was brought up by Ralf Wildenhues in a thread on automake-patches.
>
> Automake generally orders all of its variable settings before all of the user
> ones (so the user ones are preferred).  But when one overrides e.g. bindir in
> a Makefile.am, that variable doesn't get reordered to the user part, because
> it is actually automake-set before it is overridden.  The issue is exposed in
> the attached testcase.
>
> It's still not clear to me whether this is a bug or a feature, but I thought
> that entering it into the Automake bug database would be a good idea anyway.
>
> Regards,
>   Stefano
>
>
>
> #! /bin/sh
>
> # Test that := definitions work as expected at make time, even when
> # whey involve user-overridden automake-set variables.
> #
> # Currently, this test doesn't work, because automake generally orders
> # all of its variable settings (e.g. bindir and the like) before all
> # of the user ones.  Even when  bindir is overridden, it doesn't get
> # reordered to the user part.  Might this be considered an automake bug?
>
> required=GNUmake
> . ./defs || Exit 1
>
> set -e
>
> cat >> configure.in << 'END'
> AC_OUTPUT
> END
>
> cat > Makefile.am << 'END'
> BAR := $(bindir)
> BAZ = $(bindir)
> bindir = foo
> .PHONY: test
> test:
>        test x'$(bindir)' = x'foo'
>        test x'$(BAZ)' = x'foo'
>        test x'$(BAR)' = x
> END
>
> $ACLOCAL
> $AUTOCONF
> $AUTOMAKE -Wno-portability
>
> ./configure
> $MAKE test
>
> :
>
>

Message #11 received at 7562 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Jack Kelly <jack <at> jackkelly.name>
Cc: 7562 <at> debbugs.gnu.org
Subject: Re: bug#7562: automake-set variables don't get properly reordered
	when overriden in Makefile.am
Date: Sun, 5 Dec 2010 21:50:52 +0100

On Sunday 05 December 2010, Jack Kelly wrote:
> Remark: This may be unrelated.
> 
> I don't know about overriding in Makefile.am, but overriding $(prefix)
> is important for supporting GNU Stow. To set up a package for Stow,
> you configure for one prefix and install under another (note that this
> isn't the same as using $(DESTDIR) - that dumps the whole directory
> tree under the target path).
> 
> Example:
> 
> ./configure --prefix=$HOME
> make
> make prefix=$HOME/stow/foo-x.y.z
> cd $HOME/stow
> stow foo-x.y.z
> 
> So whatever you do with the variable ordering, I hope it doesn't break
> overrides from the command line.
> 
Oh, it must absolutely not break that, since the behaviour you want is
mandated by the GNU coding standards, and cannot be changed.  Breaking
it would be a *grave* automake bug.  So I guess you're safe in this
respect.

Regards,
  Stefano

Message #14 received at 7562 <at> debbugs.gnu.org (full text, mbox):

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Jack Kelly <jack <at> jackkelly.name>, 7562 <at> debbugs.gnu.org
Subject: Re: bug#7562: automake-set variables don't get properly reordered
	when overriden in Makefile.am
Date: Sun, 5 Dec 2010 22:22:13 +0100

Hello,

* Stefano Lattarini wrote on Sun, Dec 05, 2010 at 09:50:52PM CET:
> On Sunday 05 December 2010, Jack Kelly wrote:
> > make prefix=$HOME/stow/foo-x.y.z

> > So whatever you do with the variable ordering, I hope it doesn't break
> > overrides from the command line.
> > 
> Oh, it must absolutely not break that, since the behaviour you want is
> mandated by the GNU coding standards, and cannot be changed.  Breaking
> it would be a *grave* automake bug.  So I guess you're safe in this
> respect.

Of course, the GNU Coding Standards are a bit oblivious of existing
limitations of non-GNU make implementations at this point; see
  info Autoconf "Macros and Submakes"

Oh well.  Another issue completely unrelated to this PR ...  ;-)

Cheers,
Ralf

Message #17 received at 7562 <at> debbugs.gnu.org (full text, mbox):

From: Jack Kelly <jack <at> jackkelly.name>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 7562 <at> debbugs.gnu.org
Subject: Re: bug#7562: automake-set variables don't get properly reordered
	when overriden in Makefile.am
Date: Mon, 6 Dec 2010 08:28:37 +1100

On Mon, Dec 6, 2010 at 7:50 AM, Stefano Lattarini
<stefano.lattarini <at> gmail.com> wrote:
> On Sunday 05 December 2010, Jack Kelly wrote:
>> Remark: This may be unrelated.
>>
>> I don't know about overriding in Makefile.am, but overriding $(prefix)
>> is important for supporting GNU Stow. To set up a package for Stow,
>> you configure for one prefix and install under another (note that this
>> isn't the same as using $(DESTDIR) - that dumps the whole directory
>> tree under the target path).
>>
>> Example:
>>
>> ./configure --prefix=$HOME
>> make
>> make prefix=$HOME/stow/foo-x.y.z
>> cd $HOME/stow
>> stow foo-x.y.z
>>
>> So whatever you do with the variable ordering, I hope it doesn't break
>> overrides from the command line.
>>
> Oh, it must absolutely not break that, since the behaviour you want is
> mandated by the GNU coding standards, and cannot be changed.  Breaking
> it would be a *grave* automake bug.  So I guess you're safe in this
> respect.

I'm glad you're on top of that. I just wanted to bring it up in case
it had been forgotten.

Thanks.

-- Jack

Message #20 received at 7562 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
Cc: Jack Kelly <jack <at> jackkelly.name>, 7562 <at> debbugs.gnu.org
Subject: Re: bug#7562: automake-set variables don't get properly reordered
	when overriden in Makefile.am
Date: Sun, 5 Dec 2010 22:35:06 +0100

On Sunday 05 December 2010, Ralf Wildenhues wrote:
> Hello,
> 
> * Stefano Lattarini wrote on Sun, Dec 05, 2010 at 09:50:52PM CET:
> > On Sunday 05 December 2010, Jack Kelly wrote:
> > > make prefix=$HOME/stow/foo-x.y.z
> 
> > > So whatever you do with the variable ordering, I hope it doesn't break
> > > overrides from the command line.
> > > 
> > Oh, it must absolutely not break that, since the behaviour you want is
> > mandated by the GNU coding standards, and cannot be changed.  Breaking
> > it would be a *grave* automake bug.  So I guess you're safe in this
> > respect.
> 
> Of course, the GNU Coding Standards are a bit oblivious of existing
> limitations of non-GNU make implementations at this point; see
>   info Autoconf "Macros and Submakes"
> 
> Oh well.  Another issue completely unrelated to this PR ...  ;-)
> 
Well, let's just say the `prefix' overriding should continue to work with
GNU make as it did before ;-) ...

Regards,
  Stefano

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.