Re: checking automake version in configure.ac

[Ralf Corsepius]

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