Re: automake fun
On Tue, 20 Nov 2001, Colin Walters wrote:
> 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.
4) don't think about it, and let the "missing" script handle it -- which
basically doesn't do much more than touch'ing the relevant files.
<snip>
--
wouter dot verhelst at advalvas dot be
"Human knowledge belongs to the world"
-- From the movie "Antitrust"
Reply to: