]] Ian Jackson
Hi,
| 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.
(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.
| 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.
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.
| > 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.
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.
| 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.
I think the preferred form is whatever is in its git (or whatever VCS
they are using) repository.
Regards,
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
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/87aagtlm6l....@qurzaw.varnish-software.com
