On 10/06/2009 04:52 PM, Eric Blake wrote:
Ralf Corsepius<rc040203<at> freenet.de> writes:
... I don't want that behavior. I just want to add a feature, not to
forbid a user to rebuild the files.
The desired behavior TOTALLY makes sense (although this is an automake
question, not an autoconf question)
> - an example is the use of color-tests
when available, with a clean fallback to no color-tests if an older
automake was sufficient for everything else.
Well, this is an entirely different use-case.
This is changing the configure's behavior at configure run-time. It is
not the running "autogen.sh" (autoreconf) case.
Huh?
Citing from the 1st and 2nd answer to this thread:
Somebody >> If my guessing is right, the popular method would
Somebody >> be packing autogen.sh with version checking.
Vincent > we actually pack autogen.sh. Checking the version of
Vincent > automake in it and use it in configure.ac is indeed
Vincent > a solution.
Vincent > Is there a better one ?
And whether version checking is an appropriate means/good approach in
general at all, is a different question.
m4_ifdef([AM_SILENT_RULES]) is as good as it gets - it's a feature test, which
is better than a version check. As long as new automake features are always
given a corresponding feature check ability, then it is possible to write
configure.ac that takes advantage of the features when present without choking
when used with older automake versions.
IMNSHO,
a) AM_SILENT_RULES are harmful (I know, you know that I think about this
(mal-) "feature" this way - Working around the issues they are causing
in Fedora packaging is a major nuissance.)
b) having them as optional feature at configure-run-time introduces
non-deterministic behavior.
Ralf
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
