Re: AM_COND_IF for earlier Automake

[Dave Hart]

On Sat, Dec 18, 2010 at 11:56 AM, Ralf Wildenhues
<address@hidden> wrote:
> Hello Dave,
>
> * Stefano Lattarini wrote on Sat, Dec 18, 2010 at 11:18:04AM CET:
>> On Saturday 18 December 2010, Dave Hart wrote:
>> > I'd like a package I depend on to use AM_COND_IF, but it does not want
>> > to demand Automake 1.11 at this point.  Does this seem like a
>> > reasonable solution?
>
>> BTW, I see that automake 1.11 also traces the macros _AM_COND_IF,
>> _AM_COND_ELSE and _AM_COND_ENDIF, which are not present nor traced in
>> 1.10, so my suggestion above might still be insufficient in some
>> situations (if not all).
>
> Exactly.  AC_CONFIG_* instances within AM_COND_IF arguments will be
> mistreated.

I do not expect AM_COND_IF magic regarding AC_CONFIG_FILES to work
correctly when used with pre-1.11 Automake.  Rather, I'm simply
looking for the m4sh if/else to work.

My package _does_ simply require Automake 1.11, as it is needed to get
correct results with our nested subpackages.  See this unrequited
message:

http://lists.gnu.org/archive/html/automake/2010-11/msg00135.html

However, the libopts author does not seem as motivated as me to force
other libopts clients to upgrade to Automake 1.11 at this point.  So
my interest is getting a AM_COND_IF-alike that will do the right thing
m4sh-wise on newer and older Automake.  I only care about the
AC_CONFIG_FILES magic working correctly under Automake 1.11 and later.

>> My advice is: just require Automake 1.11.  That's not unreasonable,
>> since that's anyway a requirement for developers, not for users.
>
> Agreed.
>
> Also, your implementation shares the bug fixed in v1.11-152-g6f6e328:
>
>  - The AM_COND_IF macro also works if the shell expression for the conditional
>    is no longer valid for the condition.

I'll attempt to integrate that patch in my ripoff, thanks.

Dave Hart