* Marcin Owsiany <porri...@debian.org> [110315 23:30]:
> The current best practice for dealing with packages using GNU autotools
> (as described in /usr/share/doc/autotools-dev/README.Debian.gz) is to
> run autoreconf in a prerequisite of a build target, and to remove its
> results in the clean target.
Well, here I need to contradict. As long as upstream's build system
works and does not need any modifications, redoing that with other
versions is just an unneeded modification of upstream sources.
> * for every autoool, maintain an anti-autotool that would know how to
> revert the actions of its counterpart.
I doubt that is feasible. There are things like files where a default
version is installed if there is non of the maintainer. Things like
that cannot be reverted without knowing what the original state was.
And I'm not sure there is nowhere a way to let maintainer-given actions
run at that time.
> Basically just like
> automake-generated files encode the knowledge of how to "make clean"
> after a "make all", there would need to be a "-clean" counterpart for
> every autotool that autoreconf can call.
There is maintainer-clean, but that has semantics that the maintainer
has to decide. This can be "revert to the manually edited files that
are stored in VCS", but also something different.
(For example automake manual also suggests another rule-set where
maintainer-clean should not remove configure).
Bernhard R. Link
--
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/20110316093020.ga19...@pcpool00.mathematik.uni-freiburg.de
