bug#8784: [PATCH] {maint} distcheck: add support for AM_DISTCHECK_CONFIGURE_FLAGS (was: Re: bug#8784: Support developer-reserved AM_DISTCHECK_CONFIGURE_FLAGS)

Reference: On Thursday 02 June 2011, Stefano Lattarini wrote: > Severity: wishlist > > Hello automakers. > > Continuing with the good trend of avoiding to impinge on the user > namespace, we should start supporting AM_DISTCHECK_CONFIGURE_FLAGS

bug#8718: error when using nested conditionals

On Friday 10 June 2011, Bruno Haible wrote: > Peter, > > > how about the following alternative (for all conditionals, or just for some > > of them, e.g., those under the regime of AM_IGNORE_UNDEFINED_CONDITIONALS): > > Replace the AC_MSG_ERROR() above by a warning and set both $1_TRUE and > > $1_F

bug#8718: error when using nested conditionals

Peter, > how about the following alternative (for all conditionals, or just for some > of them, e.g., those under the regime of AM_IGNORE_UNDEFINED_CONDITIONALS): > Replace the AC_MSG_ERROR() above by a warning and set both $1_TRUE and > $1_FALSE to something that, when not hidden in a false branc

bug#8718: error when using nested conditionals

> Since the usual way to implement nestable behaviour in Autoconf is > m4_pushdef / m4_popdef Another idea would to be m4_pushdef AM_CONDITIONAL itself. If you add a third parameter to AM_CONDITIONAL, denoting the conditions in which the conditional needs to be defined, then gnulib could emit cod

bug#8718: error when using nested conditionals

On Fri, 10 Jun 2011, Stefano Lattarini wrote: Nope, it gets the information from the fact each AM_CONDITIONAL invocation does this: AC_CONFIG_COMMANDS_PRE( [if test -z "${$1_TRUE}" && test -z "${$1_FALSE}"; then AC_MSG_ERROR([[conditional "$1" was never defined. Usually this means

bug#8718: error when using nested conditionals

Jack Kelly wrote: > AM_IGNORE_UNDEFINED_CONDITIONALS(REGEX) ignores > "undefined-conditional" errors for conditions that match REGEX. With this proposal, gnulib would have to turn off all "undefined-conditional" errors, that is, use a regex of [.*]. That's because as exemplified in the previous ma

bug#8718: error when using nested conditionals

On Fri, Jun 10, 2011 at 6:19 PM, Stefano Lattarini wrote: > Here is my idea: 'AM_IGNORE_UNDEFINED_CONDITIONALS' can accept two > arguments, "yes" and "no" (defaulting to "yes" if no argument is given). > The idea is that an usage like: > > -snip- > > will cause the generated configure to check tha

bug#8718: error when using nested conditionals

Hi Stefano, > 'AM_IGNORE_UNDEFINED_CONDITIONALS' can accept two > arguments, "yes" and "no" (defaulting to "yes" if no argument is given). > The idea is that an usage like: > > AM_CONDITIONAL([FOO], [:]) > AM_IGNORE_UNDEFINED_CONDITIONALS([yes]) > if test -n "$user_flag"; then > AM_CON

bug#8718: error when using nested conditionals

On Friday 10 June 2011, Bruno Haible wrote: > Hi Stefano, > > > Cannot you simply initialize the > > automake conditionals you might need and that you know might be called > > conditionally to (possibly dummy) defaults in gl_INIT or gl_EARLY or > > something like that? > > No, I cannot do that.