autoconf
[Top][All Lists]
Advanced

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

Re: problem with ifelse


From: Eric Blake
Subject: Re: problem with ifelse
Date: Thu, 05 Mar 2009 06:09:17 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19) Gecko/20081209 Thunderbird/2.0.0.19 Mnenhy/0.7.6.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Vincent Torri on 3/4/2009 1:34 PM:
> 
> dnl use: ECORE_CHECK_MODULE(Foo, default-enabled[, dependancy[,
> ACTION-IF-FOUND[, ACTION-IF-NOT-FOUND]]])
> AC_DEFUN([ECORE_CHECK_MODULE],
> [
> pushdef([UP], translit([$1], [a-z], [A-Z]))dnl
> pushdef([DOWN], translit([$1], [A-Z], [a-z]))dnl

Consider using the m4sugar namespace.  We have threatened to add warnings
when using the raw m4 namespace from within configure scripts, because it
is too easy to run into conflicts.  For that matter, why not use
m4_toupper and m4_tolower, instead of rewriting them yourself?  Not to
mention that those macros are more robust to arguments that include
potential macro names (your version is underquoted, and would end up
expanding such a macro).

m4_pushdef([UP], m4_toupper([[$1]]))dnl

> 
> have_ecore_[]DOWN="no"
> ecore_[]DOWN[]_cflags=""
> ecore_[]DOWN[]_libs=""

Again, if DOWN corresponds to a macro name (such as if you did
ECORE_CHECK_MODULE([Index]), it will be multiply expanded; when using DOWN
as a variable to hold an arbitrary text, it is safer to reference that
text via m4_defn([DOWN]) rather than expansion.  But in general it works
without going to these extremes (very seldom do you have a module name
that matches an m4 macro name, particularly when m4 macros stick to their
namespace, which is why we prefer the m4sugar namespace over raw m4 macro
names), but it never hurts to be more robust.  While it doesn't hurt to
use extra "" in shell assignments, in this case you can safely omit them.

have_ecore_[]m4_defn([DOWN])=no

> 
> ifelse([$2], [no],
> [

I strongly suggest you use m4_if instead of ifelse.

>    AC_ARG_ENABLE(ecore-[]DOWN,
>       [AC_HELP_STRING(
>           [--enable-ecore-[]DOWN],
>           [enable the ecore_[]DOWN module. [[default=disabled]]])],

Overquoting.  I'm guessing you want DOWN expanded here, which means you
need this line to be:

  [enable the ecore_]DOWN[ module.  [[default=disabled]]])],

or even

  [enable the ecore_]m4_defn([DOWN])[ module.  [[default=disabled]]])],


> 
> AC_MSG_CHECKING(whether ecore_[]DOWN module is to be built)

Likewise underquoted.  Canonically, this would be:

AC_MSG_CHECKING([whether ecore_]DOWN[ module is to be built])

> 
> if test "x$want_ecore_[]DOWN" = "xyes" ; then
>   if test "x$3" = "x" -o "x$3" = "xyes" ; then
>     AC_DEFINE(BUILD_ECORE_[]UP, 1, [Build Ecore_$1 Module])

Underquoted.  For consistency, I would write this as:

AC_DEFINE([BUILD_ECORE_]UP, [1], [Build Ecore_$1 Module])

>     have_ecore_[]DOWN="yes"
>     ecore_[]DOWN[]_libs="-lecore_[]DOWN"
>     AC_MSG_RESULT([yes])
>   else
>     AC_MSG_RESULT([no (dependancy failed)])

Typo.  dependency

>   fi
> else
>   AC_MSG_RESULT([no])
> fi
> 
> AM_CONDITIONAL(BUILD_ECORE_[]UP, test "x$have_ecore_[]DOWN" = "xyes")

Underquoted.  And since you control the contents of $have_ecore_..., you
can guarantee that it won't trip up test:

AM_CONDITIONAL([BUILD_ECORE_]UP, [test "$have_ecore_]DOWN[" = yes])

> 
> if test "x$have_ecore_[]DOWN" = "xyes" ; then
>   ifelse([$4], , :, [$4])

Perfect use case for m4_default([$4], [:]) rather than ifelse.

> else
>   ifelse([$5], , :, [$5])
> fi
> 
> AC_SUBST(ecore_[]DOWN[]_cflags)
> AC_SUBST(ecore_[]DOWN[]_libs)
> 
> popdef([UP])
> popdef([DOWN])

Prefer m4_popdef.

> ])
> 
> 
> The problem is with
> 
> ifelse([$2], [no] *****)
> 
> Whatever the 2nd parameter is ("yes" or "no"), it seems that the test
> always fails. I try with m4_if, without success too.

Without an explanation of what you think is failing, I'm assuming that it
was the fact that DOWN wasn't always expanded where you wanted it.  But
explaining that, or else showing what failure you are actually
encountering compared to your expectations, would make it easier to know
that I'm helping.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmvzv0ACgkQ84KuGfSFAYDB7gCgkZQ5Bu3/p5O3QLowQ+JnI8X7
GtAAniI5wswwaXhq3lnJCBZr55KHTG9U
=WQJ7
-----END PGP SIGNATURE-----




reply via email to

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