|
From: | Ralf Corsepius |
Subject: | Re: checking automake version in configure.ac |
Date: | Tue, 06 Oct 2009 17:49:52 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3 |
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-testswhen 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
[Prev in Thread] | Current Thread | [Next in Thread] |