On Sat, Dec 18, 2010 at 11:56 AM, Ralf Wildenhues <ralf.wildenh...@gmx.de> 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
