Ralf Wildenhues <ralf.wildenh...@gmx.de> 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
