GNU bug report logs -
#31465
Automake 1.16 breaks custom dependency handling
Previous Next
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.
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):
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):
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.