Adam Borowski writes ("Re: Best practice for cleaning autotools-generated
files?"):
> Ie, consistently with all regular commands in a makefile: if a source file
> has been modified, everything that is generated from that source needs to be
> rebuilt.
>
> Which works just fine if timestamps haven't been trampled over.
No, it doesn't work if the auto* on the system is not compatible with
the auto* in the package, which happens very often. It doesn't happen
often to people who are building packages for Debian courgette /on/
Debian courgette. But it happens to Debian's users and downstreams a
lot.
Furthermore when the auto* incompatibility strikes, it can be a very
hard hole to dig out of. If there is some problem with rejected
patches or timestamps, but a working and compatible auto* setup, it is
trivial to rerun auto* to fix the problem.
The design of autoconf is predicated on the idea that people who are
building the package are given a portable configure as part of the
source package, so there is no need to have good compatibility between
configure.in and various versions of autoconf.
I don't understand why the current autoconf maintainers have lost
sight of this. Perhaps it's because they're actually the automake
maintainers who maybe never understood it.
> AM_MAINTAINER_MODE is also strongly depreciated and discouraged.
It is discouraged and deprecated (not depreciated!) by the autotools
maintainers. But the autotools maintainers are wrong.
> Using it, you are effectively patching compiler output rather than
> source.
I'm not sure what you mean by "you are patching". Automatic systems
for managing source code will indeed edit compiled output as well as
input, but with AM_MAINTAINER_MODE no human ever needs to edit
compiled output.
There is nothing wrong with automated systems such as version control
systems and patch systems including representations of changes to
generated files, provided the generated files are portable.
> You're likely to end up shipping things without source, obviously failing
> DFSG and being in a breach of the GPL. There's no way you can argue for
> ./configure to be a preferred form for modification...
I think this is a highly unlikely scenario. No-one is suggesting
removing configure.in et al and there is no plausible mechanism that
might result in it vanishing. Since often the Debian packaging is
going to involve editing auto* input, the buildability from scratch
will be tested on every new upstream version.
Also, I could argue that the configure.in without configure is
likewise not the preferred form for modification. The question surely
is "preferred by who". I think that the preferred form for
modification of "ls" includes coreutils's Makefile, Makefile.in and
configure as well as its Makefile.am and configure.in etc.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/19842.11967.790255.179...@chiark.greenend.org.uk
