Re: Best practice for cleaning autotools-generated files?
Tollef Fog Heen writes ("Re: Best practice for cleaning autotools-generated files?"):
> | Adam Borowski writes ("Re: Best practice for cleaning autotools-generated files?"):
> | 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.
>
> (I disagree with it happening very often, but that's a minor point.)
>
> If you can't regenerate the autofoo files with the autofoo that we ship
> we're not actually shipping source any more than shipping preprocessed C
> source files would be considered shipping source. Any such
> incompatibility is a fairly serious bug.
I agree with that. But Debian source packages are not only built on
the identical same environment that we build them.
We should be providing source packages which are maximally useful to
users of related distros, whether that's derivatives with different
versions of autoconf, or different versions of Debian.
> | 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.
>
> This might have been true once upon a time. It's becoming less and less
> common with many people building VCS-es instead of using a tarball.
The _design_ is still predicated on this assumption. The autotools
maintainers' behaviour with respect to backward compatibility is still
predicated on this assumption.
What has happened is simply that the assumption is becoming false.
I agree that many people nowadays do not provide autotools output as
part of their vcs trees or sometimes even tarballs. They do this
because the autotools maintainers recommend it, and because of threads
like this one.
But those people are doing it wrong.
Either (a) autotools needs to be redesigned so that it no longer
assumes that the autotools output form part of the source code which
is distributed to people who want to modify and build the package, or
(b) we need to make that assumption true.
(a) is obviously too hard. (b) is very simple.
> Personally, I wish I could treat configure and its siblings with the
> same amount of attention I treat gcc's intermediate files with: none,
> unless I need to debug something weird.
The analogy is completely flawed.
One can compile source code for gcc with pretty much any version of
gcc; whereas, autotools source code can only reliably be compiled with
the specific version of autotools for which it is intended.
gcc's intermediate files do not work except on the exact system where
they are built; whereas, autotools output files are highly portable
aned can be used unaltered anywhere regardless of processor, autotools
version, or even the entire build and target operating systems.
> | 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.
>
> We have to ship _source_ and the necessary tools to get from source to
> whatever ends up in binaries. It's not ok to ship configure scripts we
> can't rebuild any more than shipping .jar files we can't rebuild or
> PDF-es we can't rebuild. People go to great lengths to rebuild
> documentation and similar that upstream ship, and I see no reason we
> should not go to the same lengths to rebuild the build system.
Did you read what I wrote ? Let me say it again a few times:
No-one is suggesting removing configure.in et al.
I agree that we must continue to ship autotools input.
Yes, the source code input to autotools must continue to be in all vcs
repositories and source packages.
Indeed, the autotools input must not be deleted.
BUT we should ALSO provide the autotools-generated files.
The reason why people go to these great lengths to rebuild
documentation is to make sure that it can be done. This does not
apply to autoconf output.
As I say, it will in practice be essential to rerun the autotools
when we package every upstream release anyway. So there is very low
risk that we will ship package where autotools can't be rerun using
the tools we're shipping.
Ian.
Reply to: