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

Previous Next

Package: automake;

Reported by: Stefano Lattarini <stefano.lattarini <at> gmail.com>

Date: Sun, 5 Dec 2010 17:31:02 UTC

Severity: wishlist

Full log


View this message in rfc822 format

From: Jack Kelly <jack <at> jackkelly.name>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 7562 <at> debbugs.gnu.org
Subject: 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
>
> :
>
>




This bug report was last modified 14 years and 195 days ago.

Previous Next


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