automake fun
So,
A lot of packages out there use automake to generate their Makefile.in
files. The problem with this is that automake puts the following
rules in:
,----[ Makefile.in rules ]
|
| $(srcdir)/Makefile.in: Makefile.am $(top_srcdir)/configure.in $(ACLOCAL_M4)
| cd $(top_srcdir) && $(AUTOMAKE) --gnu Makefile
|
| Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status $(BUILT_SOURCES)
| cd $(top_builddir) \
| && CONFIG_FILES=$@ CONFIG_HEADERS= $(SHELL) ./config.status
|
| $(ACLOCAL_M4): configure.in
| cd $(srcdir) && $(ACLOCAL)
|
| config.status: $(srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
| $(SHELL) ./config.status --recheck
| $(srcdir)/configure: $(srcdir)/configure.in $(ACLOCAL_M4) $(CONFIGURE_DEPENDENCIES)
| cd $(srcdir) && $(AUTOCONF)
`----
These rules can cause automake and/or autoconf to be rerun if
timestamp skew occurs (from, say, the application of a Debian diff).
Now, there are several solutions to this problem.
1) Build-Depend on autoconf and automake: this doesn't really solve
the problem. Rerunning autoconf and automake is upstream's job.
2) Change all the timestamps such that those rules will never be
executed.
3) Comment out those rules in all the Makefile.in files as part of
your Debian diff.
Personally, I am having trouble deciding between 2 and 3. Option 3
seems the cleanest, but it is quite manual and requires one to
manually update if upstream reruns automake. Option 2 requires find
+ touch, which is very ugly.
I think we should decide on the One True Way to handle this; any
opinions?
Reply to: