Hi Mathieu,
Thanks for the quick reply.
What is not clear to me is the reasoning of that heuristic. You seems
to suggest that it has been introduced to avoid having to know the order
in which autoconf, aclocal, automake, ... has to be run. Have you any
reference regarding that?
I've been looking through my old mail about this. I can't reconstruct
the whole trail, but this message from rms to me seems to be the crux of
the "don't delete configure" special case (this is the whole message and
I have no other direct context, but still).
Date: Sat, 19 Sep 92 23:42:28 -0400
From: r...@gnu.ai.mit.edu (Richard Stallman)
To: k...@cs.umb.edu
Subject: realclean: rm configure
You can't reconstruct configure with the makefile
if there is no configure.
That was true in 1992 (no autoreconf :), but is routinely not true
today.
Francois, Tom Tromey, Akim Demaille, Jim Meyering, I, and others were
going through many iterations of what should be deleted in which target
in those years. I can't pin down the exact source of that heuristic
though.
I would guess that the reason is more that this command might be run
from a tarball
I don't see why that's an issue. If an installer runs maintainer-clean
after unpacking a tarball, they are responsible for their own actions.
That's why the target is named *maintainer*-clean :).
https://www.gnu.org/prep/standards/html_node/Standard-Targets.html
talks about this in explicit detail. (It also implies that Makefile.in
files should be deleted, by the way. Hmm.)
and that if the package builder doesn't know that Autotools is now
needed as a dependency, that person is left without any instruction
There are always instructions ...
Can you explain why this step would be too much for you?
Because I might (and usually do) have newer versions of the common files
than what missing would copy (ie, updated since the last Automake
release). Regardless, if you want to put build-aux (or whatever) into
the example in the manual, I don't object.
Best,
Karl
