Hello automakers.
The recent commit `v1.11-512-g40c3432', required to fix automake bugs #8485
and #8526, has re-introduced the bug reported by Ignacy Gawedzki in his
message "subdir-objects, dirstamps and --disable-dependency-tracking (bug?)",
posted to the automake list in March 2011. I'm thus registering this
bug in the automake tracker so that we won't forget about it.
Regards,
Stefano
-*-*-*-
Reference:
<http://lists.gnu.org/archive/html/automake/2011-03/msg00124.html>
a.k.a.:
<http://thread.gmane.org/gmane.comp.sysutils.automake.general/12768>
-*-*-*-
Original message follows ...
-*-*-*-
Hi,
I suspect I found a bug in automake 1.11.1 .
I have a project in which some program has .ll and .yy sources that must be
generated by flex and bison. It also happens I need to have specific
preprocessor options passed to that program using a _CPPFLAGS variable. This
makes everything produced for that program prefixed with the program name.
Besides, I need to use the subdir-objects automake option.
Now the problem is that some subdirectories are not created automatically in
$(builddir) as expected and I think I have found why. It happens when
configure is called with --disable-dependency-tracking, as is usually the case
when called through debhelper.
In the attached tarball, there is a minimal setup illustrating the problem.
Try to configure and build the project in a separate build directory and you
should be able to observe how automake fails to create $(builddir)/src before
calling ylwrap to generate src/bug-scanner.cc .
The Makefile has the following rule (number 1):
src/bug-scanner.$(OBJEXT): src/$(am__dirstamp) \
src/$(DEPDIR)/$(am__dirstamp)
But the bug_CPPFLAGS line in Makefile.am ultimately leads to the production of
the following rule (number 2):
src/bug-scanner.o: src/scanner.cc
...
Whereas there is *no* rule of the kind :
src/scanner.cc: src/$(am__dirstamp)
...
This looks like src/scanner.cc gets regenerated *before* src/$(am_dirstamp)
gets a chance to be considered, supposedly because of the explicit rule number
2.
Does anybody know of a clean fix/workaround?
Thanks.
Ignacy