[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#31465: Automake 1.16 breaks custom dependency handling
From: |
Eric Blake |
Subject: |
bug#31465: Automake 1.16 breaks custom dependency handling |
Date: |
Tue, 15 May 2018 16:23:42 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 |
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@ @address@hidden(DEPDIR)/address@hidden@
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