Re: Lintian: outdated-autotools-helper-file
Am Montag, den 11.02.2008, 10:54 +0100 schrieb David Paleino:
> Il giorno Mon, 11 Feb 2008 10:53:48 +0100
> Bas Wijnen <shevek@fmf.nl> ha scritto:
>
> > I suggest to mandate "remove all generated files in the clean target"
> > (formulated in a way which includes "generated by upstream", not only
> > "generated by the build target), which implies "rebuild everything in
> > the build target".
>
> I fully agree with you here: the build target should also build Makefile.in
> from Makefile.am, for example. Thus we clean *.in, *.sub, *.guess, in the clean
> target.
The files you mention belong to the maintainer-clean target. To remove
them in the debian/rules clean target you would often have to repackage
the source tarball, which often includes patching, because many
autotools-based build environments do not fully implement
maintainer-clean. Otherwise you would need to duplicate maintainer-clean
in the debian/rules clean target (good luck with large source archives,
maybe including even sub-projects!). You further need to build depend on
the whole autotools chain + additional tools like gnome-doc-utils or
intltool or ....
We simply copy config.sub and config.guess into the build directory for
some years now and I never observed any problem with this.
I'm really wondering why you want to make the situation complicated?
> And, as a sidenote, I've just faced this. I patched a Makefile.am, and wasn't
> seeing any result.
This project very probably used the AM_MAINTAINER_MODE macro. Enable the
maintainer-mode with --enable-maintainer-mode.
> I also had to patch Makefile.in. That's non-sense to me.
Why do you patch Makefile.am? It just makes sense, when you manipulate
or change macros (e.g. make libraries convenience libraries). If you
just change a path or if you want to remove a binary from
installation ... then simply patch Makefile.in directly. There is often
no reason to patch Makefile.am.
Regards, Daniel
Reply to: