[Top][All Lists]

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

Re: using color-tests backwards-portably

From: Ralf Wildenhues
Subject: Re: using color-tests backwards-portably
Date: Fri, 14 Aug 2009 20:23:17 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hello Ben,

* 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).

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.

I would hate to have to duplicate this functionality in m4, esp. since
we definitely also need it at automake run time for those options listed
in the AUTOMAKE_OPTIONS variable.


reply via email to

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