[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: using color-tests backwards-portably

From: Ben Pfaff
Subject: Re: using color-tests backwards-portably
Date: Fri, 14 Aug 2009 13:22:20 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Ralf Wildenhues <address@hidden> writes:

> * Ben Pfaff wrote on Fri, Aug 14, 2009 at 06:33:14PM CEST:
>> As an alternative, could Automake provide an API that allows
>> users to say "if feature X is supported, then expand this
>> code"?  For example:
>>   AM_FEATURE_PREREQ([color-tests],
>>                     [AM_INIT_AUTOMAKE([foreign color-tests])],
>>                     [AM_INIT_AUTOMAKE([foreign])])
>> This seems to me more in keeping with the Autoconf philosophy.
> Yes, the idea sounds better.  But without also exposing something like
> AM_SET_OPTION, it would not scale: with the above, you might have
> exponentially many cases to cater to as user (e.g., 8 for 3 features,
> if you really want to be fully version-agnostic by ignoring that feature
> X was introduced after feature Y).

Well, I suppose that something like this would work:
        AM_INIT_AUTOMAKE([foreign AM_OPTIONAL_FEATURE([color-tests])])
where AM_OPTIONAL_FEATURE expands to its argument if that feature
is supported and to the null string otherwise.  (I don't
understand the m4 quoting rules well enough to know whether I
have the quoting right here.)

> One major detail of this idea is that now, aclocal or the macro code
> supplied with Automake would need to know about the set of options that
> are supported.  It doesn't do so now; only _process_option_list in
> lib/Automake/ used at automake run time knows.  Also, the set
> of options isn't just a set of fixed strings, but includes some regexps.

Ben Pfaff

reply via email to

[Prev in Thread] Current Thread [Next in Thread]