GNU bug report logs - #31465
Automake 1.16 breaks custom dependency handling

Previous Next

Package: automake;

Reported by: Sander Niemeijer <sander.niemeijer <at> stcorp.nl>

Date: Tue, 15 May 2018 20:39:01 UTC

Severity: normal

Tags: wontfix

Done: Mike Frysinger <vapier <at> gentoo.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 31465 in the body.
You can then email your comments to 31465 AT debbugs.gnu.org in the normal way.

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-automake <at> gnu.org:
bug#31465; Package automake. (Tue, 15 May 2018 20:39:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sander Niemeijer <sander.niemeijer <at> stcorp.nl>:
New bug report received and forwarded. Copy sent to bug-automake <at> gnu.org. (Tue, 15 May 2018 20:39:02 GMT) Full text and rfc822 format available.

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

From: Sander Niemeijer <sander.niemeijer <at> stcorp.nl>
To: bug-automake <at> gnu.org
Subject: Automake 1.16 breaks custom dependency handling
Date: Tue, 15 May 2018 18:56:56 +0200
I have a software package that uses SWIG to dynamically generates .c files.
With automake 1.15 and earlier I was able to add my own dependency rules for this by adding some custom entries to the Makefile.am.

A small reduced example of the approach I am using:

@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/foo.Pc <at> am__quote@

foo.c: $(srcdir)/foo.i
@AMDEP_TRUE@	source='$(srcdir)/foo.i' object='foo.c' libtool=no @AMDEPBACKSLASH@
@AMDEP_TRUE@	depfile='$(DEPDIR)/foo.Pc' tmpdepfile='$(DEPDIR)/foo.TPc' @AMDEPBACKSLASH@
@AMDEP_TRUE@	depmode='none' $(depcomp) @AMDEPBACKSLASH@
@AMDEP_TRUE@	$(SWIG) $(SWIGFLAGS) -M $(srcdir)/foo.i > $(DEPDIR)/foo.Pc
	$(SWIG) $(SWIGFLAGS) -o foo.c $(srcdir)/foo.i


This approach worked fine with previous (15.x and earlier) automake versions, but with the latest release (I tested with 1.16.1) this no longer works.

The 'Something went wrong bootstrapping makefile fragments' problem that was raised by the configure script was easily solved by adding an '# am--include-marker' to the include statement.

But after that, a call to 'make' will complain about '.deps/foo.Pc: No such file or directory'.

The problem here is that the dependency file $(DEPDIR)/foo.Pc no longer gets generated by configure (or config.status).

I have been able to work around this by overriding am--depfiles to:

am--depfiles: $(am__depfiles_remade) $(local_depfiles)

And then generate the foo.Pc file as part of the $(local_depfiles) target (using some additional custom rules).

This seems to work nicely, except that automake still keeps giving me warnings about am--depfiles being overridden, which I would like to get rid off.

The question is thus whether it would be possible to add some hook into automake to have am--depfiles depend on some additional (optional) target (that can then be used by the Makefile.am author to generate custom dependency files).
Something in the spirit of the extension mechanism that is already available for e.g. the *-hook and *-local targets.

For instance, allowing an optional am--depfiles-local target that, if it exists in the Makefile.am, will be added as dependency to am--depfiles:

am--depfiles: $(am__depfiles_remade) am--depfiles-local

which will then allow me to use:

am--depfiles-local: $(local_depfiles)

Best regards,
Sander Niemeijer





Information forwarded to bug-automake <at> gnu.org:
bug#31465; Package automake. (Tue, 15 May 2018 21:24:02 GMT) Full text and rfc822 format available.

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

From: Eric Blake <eblake <at> redhat.com>
To: Sander Niemeijer <sander.niemeijer <at> stcorp.nl>, 31465 <at> debbugs.gnu.org
Subject: Re: bug#31465: Automake 1.16 breaks custom dependency handling
Date: Tue, 15 May 2018 16:23:42 -0500
On 05/15/2018 11:56 AM, Sander Niemeijer wrote:
> I have a software package that uses SWIG to dynamically generates .c files.
> With automake 1.15 and earlier I was able to add my own dependency rules for this by adding some custom entries to the Makefile.am.
> 
> A small reduced example of the approach I am using:
> 
> @AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/foo.Pc <at> am__quote@
> 
> foo.c: $(srcdir)/foo.i
> @AMDEP_TRUE@	source='$(srcdir)/foo.i' object='foo.c' libtool=no @AMDEPBACKSLASH@
> @AMDEP_TRUE@	depfile='$(DEPDIR)/foo.Pc' tmpdepfile='$(DEPDIR)/foo.TPc' @AMDEPBACKSLASH@
> @AMDEP_TRUE@	depmode='none' $(depcomp) @AMDEPBACKSLASH@
> @AMDEP_TRUE@	$(SWIG) $(SWIGFLAGS) -M $(srcdir)/foo.i > $(DEPDIR)/foo.Pc
> 	$(SWIG) $(SWIGFLAGS) -o foo.c $(srcdir)/foo.i

Are you actually writing ALL of that in your Makefile.am?  Don't. You're 
abusing automake's internals, and when automake changes how its 
internals work, things fall apart fast.  You should only use documented 
entries into automake; any use of @AMDEP_TRUE@, @am__include@, 
@am__quote@, @AMDEPBACKSLASH@, and $(DEPDIR) falls in the realm of using 
undocumented internals.

Also, the fact that you are calling $(SWIG) two separate times per file 
may defeat the purpose of fast dependency tracking, which says that 
dependencies should be computed as a side-effect of the compilation, 
rather than as a second run of a tool.

The automake manual mentions that you can instead use the hammer of 
declaring foo.c as part of BUILT_SOURCES (so that it is guaranteed to be 
built before dependency rules kick in), or to list manual additional 
dependencies as needed, as in:

foo.$(OBJEXT): $(srcdir)/foo.i
foo.c: $(srcdir)/foo.i
	$(SWIG) $(SWIGFLAGS) -o foo.c $(srcdir)/foo.i


> I have been able to work around this by overriding am--depfiles to:
> 
> am--depfiles: $(am__depfiles_remade) $(local_depfiles)

No, that's still mucking around with automake's internals, and a bad idea.

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




Added tag(s) wontfix. Request was from Mike Frysinger <vapier <at> gentoo.org> to control <at> debbugs.gnu.org. (Fri, 10 Dec 2021 07:31:01 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 31465 <at> debbugs.gnu.org and Sander Niemeijer <sander.niemeijer <at> stcorp.nl> Request was from Mike Frysinger <vapier <at> gentoo.org> to control <at> debbugs.gnu.org. (Fri, 10 Dec 2021 07:31:01 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Fri, 07 Jan 2022 12:24:06 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 82 days ago.

Previous Next


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