GNU bug report logs - #32269
AM_INIT_AUTOMAKE, subdir-objects, and $(DEPDIR) not being set correctly

Previous Next

To reply to this bug, email your comments to 32269 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: Philip Prindeville <philipp <at> redfish-solutions.com>
To: bug-automake <at> gnu.org
Subject: AM_INIT_AUTOMAKE, subdir-objects, and $(DEPDIR) not being set
 correctly
Date: Wed, 25 Jul 2018 00:01:07 -0600

I’m using automake 1.15.1 on Fedora 28.

I changed my AM_INIT_AUTOMAKE() to include subdir-objects.

As soon as I did this, I started seeing failures like:

make[2]: Entering directory '/home/philipp/git/snt/libntp'
Makefile:902: warning: overriding recipe for target '../lib/isc/pthreads/.dirstamp'
Makefile:802: warning: ignoring old recipe for target '../lib/isc/pthreads/.dirstamp'
Makefile:905: warning: overriding recipe for target '../lib/isc/pthreads/.deps/.dirstamp'
Makefile:805: warning: ignoring old recipe for target '../lib/isc/pthreads/.deps/.dirstamp'
Makefile:964: ../lib/isc/unix/.deps/time.Po: No such file or directory
make[2]: *** No rule to make target '../lib/isc/unix/.deps/time.Po'.  Stop.
make[2]: Leaving directory '/home/philipp/git/snt/libntp'

After some head-scratching, I noticed:

$ find . -name '$*' -print
./sntp/tests/$(top_builddir)
./tests/ntpd/$(srcdir)
./libntp/$(srcdir)
$ 

and root-caused this to here:

    # Extract the definition of DEPDIR, am__include, and am__quote
    # from the Makefile without running 'make'.
    DEPDIR=`sed -n 's/^DEPDIR = //p' < "$mf"`
    test -z "$DEPDIR" && continue
    am__include=`sed -n 's/^am__include = //p' < "$mf"`
    test -z "$am__include" && continue
    am__quote=`sed -n 's/^am__quote = //p' < "$mf"`
    # Find all dependency output files, they are included files with
    # $(DEPDIR) in their names.  We invoke sed twice because it is the
    # simplest approach to changing $(DEPDIR) to its actual value in the
    # expansion.
    for file in `sed -n "
      s/^$am__include $am__quote\(.*(DEPDIR).*\)$am__quote"'$/\1/p' <"$mf" | \
         sed -e 's/\$(DEPDIR)/'"$DEPDIR"'/g'`; do
      # Make sure the directory exists.
      test -f "$dirpart/$file" && continue
      fdir=`$as_dirname -- "$file" ||
…
      as_dir=$dirpart/$fdir; as_fn_mkdir_p
      # echo "creating $dirpart/$file"
      echo '# dummy' > "$dirpart/$file"
    done

Problem is, what happens if the line you’ve read looks like:

include $(srcdir)/../lib/isc/unix/$(DEPDIR)/time.Po

after mangling that, we end up with file=$(srcdir)/../lib/isc/unix/.deps/time.Po which is obviously wrong.

Yes, $(DEPDIR) needs to be substituted out… but so does every other variable potentially, including $(srcdir) …

Either subdir-objects should handle ALL possible expansions (might require some hackery and recursively calling Makefile on each line to do expansions)… or configure should make sure that $file doesn’t match /\$(.*)/ indicating that it contains unexpanded variables… and maybe suggest using @variable@ substitutions instead if possible.

If you want to reproduce this yourselves, grab the ntp-4.8.2p11 tarball and change configure.ac and sntp/configure.ac to use AM_INIT_AUTOMAKE([… subdir-objects …]) instead.

Run:

./bootstrap
./configure --with-crypto --with-threads --disable-silent-rules --disable-local-libevent

and you’ll see the broken behavior.

Thanks,

-Philip

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

From: Philip Prindeville <philipp <at> redfish-solutions.com>
To: 32269 <at> debbugs.gnu.org
Subject: Expanding variables
Date: Wed, 25 Jul 2018 13:12:23 -0600

Since automake/autoconf are responsible for generating Makefiles, we could add something like:

val.%:
	@$(if $(filter undefined,$(origin $*)),\
		echo "$* undefined" >&2, \
		echo '$(subst ','"'"',$($*))' \
	)

var.%:
	@$(if $(filter undefined,$(origin $*)),\
		echo "$* undefined" >&2, \
		echo "$*='"'$(subst ','"'\"'\"'"',$($*))'"'" \
	)

toward the bottom.  Then if we found a line matching /\$(\([^)]+\))/ then we could look up “val.\1” from the match, and substitute that back in.  Obviously the more matches, the more iterations and the more “make -s val.\1” lookups.  But at least it would work.

If we used a Perl helper, we could find ALL of the matches, and do ALL of the lookups at once in make for more constant time, since we’d do one make process per line regardless of how many substitutions were required.

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

From: Nick Bowler <nbowler <at> draconx.ca>
To: Philip Prindeville <philipp <at> redfish-solutions.com>
Cc: 32269 <at> debbugs.gnu.org
Subject: Re: bug#32269: Expanding variables
Date: Wed, 25 Jul 2018 16:37:22 -0400

On 7/25/18, Philip Prindeville <philipp <at> redfish-solutions.com> wrote:
> Since automake/autoconf are responsible for generating Makefiles, we
> could add something like:
>
> val.%:
> 	@$(if $(filter undefined,$(origin $*)),\
> 		echo "$* undefined" >&2, \
> 		echo '$(subst ','"'"',$($*))' \
> 	)
>
> var.%:
> 	@$(if $(filter undefined,$(origin $*)),\
> 		echo "$* undefined" >&2, \
> 		echo "$*='"'$(subst ','"'\"'\"'"',$($*))'"'" \
> 	)
>
> toward the bottom.

I'm not exactly sure what the purpose of this is, but it doesn't
look like portable code, so probably not something Automake should
be generating.

But don't let that stop you.  You can add basically anything you'd
like, including the above rules, to your project's Makefile.am and
Automake will copy it through to the output.

Cheers,
  Nick

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

From: Philip Prindeville <philipp <at> redfish-solutions.com>
To: Nick Bowler <nbowler <at> draconx.ca>
Cc: 32269 <at> debbugs.gnu.org
Subject: Re: bug#32269: Expanding variables
Date: Wed, 25 Jul 2018 16:06:46 -0600

> On Jul 25, 2018, at 2:37 PM, Nick Bowler <nbowler <at> draconx.ca> wrote:
> 
> On 7/25/18, Philip Prindeville <philipp <at> redfish-solutions.com> wrote:
>> Since automake/autoconf are responsible for generating Makefiles, we
>> could add something like:
>> 
>> val.%:
>> 	@$(if $(filter undefined,$(origin $*)),\
>> 		echo "$* undefined" >&2, \
>> 		echo '$(subst ','"'"',$($*))' \
>> 	)
>> 
>> var.%:
>> 	@$(if $(filter undefined,$(origin $*)),\
>> 		echo "$* undefined" >&2, \
>> 		echo "$*='"'$(subst ','"'\"'\"'"',$($*))'"'" \
>> 	)
>> 
>> toward the bottom.
> 
> I'm not exactly sure what the purpose of this is, but it doesn't
> look like portable code, so probably not something Automake should
> be generating.
> 
> But don't let that stop you.  You can add basically anything you'd
> like, including the above rules, to your project's Makefile.am and
> Automake will copy it through to the output.
> 
> Cheers,
>  Nick


Well, the above assumes Gnu Make, yes.

How many other flavors of Make does automake/autoconf work with?

-Philip

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

From: Eric Blake <eblake <at> redhat.com>
To: Philip Prindeville <philipp <at> redfish-solutions.com>,
 Nick Bowler <nbowler <at> draconx.ca>
Cc: 32269 <at> debbugs.gnu.org
Subject: Re: bug#32269: Expanding variables
Date: Wed, 25 Jul 2018 17:15:22 -0500

On 07/25/2018 05:06 PM, Philip Prindeville wrote:

> Well, the above assumes Gnu Make, yes.
> 
> How many other flavors of Make does automake/autoconf work with?

At the moment, all of them.

Automake 2.0 (currently a work in progress if you check out the right 
branches in git) requires GNU make, for more compact makefiles at the 
expense of ditching portability to other arcane makes, now that GNU make 
is more likely to be easily obtained on modern systems.  But automake 
1.x still tries as hard as possible to produce Makefiles portable to all 
common make implementations, as long as your Makefile.am doesn't add 
non-portable code to be passed through to Makefile.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

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

From: Philip Prindeville <philipp <at> redfish-solutions.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: Nick Bowler <nbowler <at> draconx.ca>, 32269 <at> debbugs.gnu.org
Subject: Re: bug#32269: Expanding variables
Date: Wed, 25 Jul 2018 17:00:25 -0600

> On Jul 25, 2018, at 4:15 PM, Eric Blake <eblake <at> redhat.com> wrote:
> 
> On 07/25/2018 05:06 PM, Philip Prindeville wrote:
> 
>> Well, the above assumes Gnu Make, yes.
>> How many other flavors of Make does automake/autoconf work with?
> 
> At the moment, all of them.
> 
> Automake 2.0 (currently a work in progress if you check out the right branches in git) requires GNU make, for more compact makefiles at the expense of ditching portability to other arcane makes, now that GNU make is more likely to be easily obtained on modern systems.  But automake 1.x still tries as hard as possible to produce Makefiles portable to all common make implementations, as long as your Makefile.am doesn't add non-portable code to be passed through to Makefile.
> 


In the absence of Gnu make, the other choice would be to emit:

cat <<_EOF_ > /tmp/extvar$$.mk
include $(pwd)/Makefile

xyzzy:
	@echo ‘\$(variable)’
_EOF_

then we could run “variable=$(make -f /tmp/extvar$$.mk xyzzy)” from inside configure… a little uglier than using val.% as a target, but…

Previous Next

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