Re: using color-tests backwards-portably

[Ben Pfaff]

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
>> configure.ac 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/Options.pm used at automake run time knows.  Also, the set
> of options isn't just a set of fixed strings, but includes some regexps.

OK.
-- 
Ben Pfaff 
http://benpfaff.org