Re: Autoreconfing guide
Yavor Doganov <yavor@gnu.org> writes:
> Russ Allbery wrote:
>> I would still use dh-autoreconf. It's not as critical, since it's
>> unlikely to be necessary for supporting new architectures, but I think
>> the Autoconf and Automake files are better treated as source, and the
>> generated files regenerated on every build.
> However, this is not how the GNU build system is intended to be used.
Meh. I think this is a non-issue. Most free software is used in ways
that it wasn't originally designed for, and I think this is a clearly
superior way to use it on platforms where we have the right tools.
The pre-built configure scripts and Makefiles still provide valuable
portability to systems where it's hard to get all the right tools
installed.
>> This ensures that the files can still be generated from the source,
>> which in turn ensures that anyone wanting to make changes to the source
>> package will be able to do so easily.
>
> This is an obvious plus, but consider the cons:
> - It can provide non-deterministic builds for packages which misuse
> the build system (improper quotation, usage of broken third-party
> macros, etc).
No, it's not non-deterministic. It's quite deterministic; it just may be
broken with newer versions of the tools, just like badly written C code
may be broken by newer versions of the compiler. This is exactly *why*
you should always regenerate from source: so that you can catch those bugs
and *fix* them. That's part of the point of free software.
> - It can provide non-deterministic builds for legitimate use, when a
> macro changes its semantics (this used to happen quite a lot in the
> past).
Which is equivalent to saying that unmaintained Autoconf or Automake files
will *break* the builds for legitimate uses, like needing to modify some
part of the build system and finding that it can't be recreated with the
Autoconf and Automake currently available. This is why these bugs should
be flushed out and fixed.
> - It can introduce bugs for no good reason if a buggy
> Autoconf/Automake version is used (either an upstream release that
> introduced a regression or caused by a Debian patch).
Well, obviously I completely disagree with "no good reason." Yes,
actually using our build chain will uncover bugs in our build chain, so
that we can then fix them. This is very good, even if it's painful when
we find the bugs.
> - Packages may (will?) FTBFS if they're silently "upgraded" to a new
> Autoconf/Automake release that requires sourceful changes to
> configure.ac/Makefile.am's/etc and such changes are not made by the
> upstream/Debian maintainer (consider binNMUs, or the regular archive
> rebuilds).
Again, this is no different than buiding with a new C compiler. Those are
bugs that should be fixed, and better that we know about them than not.
> - All of the above can happen on a large scale if a big library
> transition is involved and some stack of packages is being rebuilt.
I find your concerns excessively alarmist.
I have been rebuilding all the Autoconf and Automake files from scratch
for all packages I maintain for quite some time now, including some very
complex packages and packages with a mess of Autoconf macros, and have had
few problems apart from a few latent upstream bugs that were flushed out
and are now fixed. The only significant problem that I had that fell into
one of your categories was the need to add:
m4_ifdef([AM_PROG_AR], [AM_PROG_AR])
to configure.ac in several of my packages due to an Automake behavior
change. I've had considerably more work to do with C++ compiler
transitions.
If a particular package uses Autoconf and Automake in such a fragile and
broken way that it keeps causing problems, maybe it's useful as a matter
of expediency to fall back on not rebuilding the files until those bugs
can be fixed. I know some packages mangled those tools very badly in the
past. But for the vast majority of packages this works fine, or with at
most minor patches that upstream is happy to take.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: