bug-autoconf
[Top][All Lists]
Advanced

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

Re: AC_CHECK_LIB inside condition


From: Ralf Wildenhues
Subject: Re: AC_CHECK_LIB inside condition
Date: Fri, 12 May 2006 10:17:53 +0200
User-agent: Mutt/1.5.11

Hi Boye,

* Boye Annfelt Høverstad wrote on Fri, May 12, 2006 at 09:57:10AM CEST:
> 
> The macro AC_CHECK_LIB seems to malfunction if it is first used inside a 
> conditionally executed block.
> 
> My relatively uninformed guess is that the first occurrence of 
> AC_CHECK_LIB is translated in the configure script to something that 
> defines certain variables.  If the condition guarding the first call to 
> AC_CHECK_LIB is false, the variables are never initialized correctly and 
> the subsequent call to AC_CHECK_LIB will fail.

Your guess is pretty close. :-)

> AC_PREREQ(2.50)
> AC_INIT([testprogram], [1], [name])
> AC_CONFIG_AUX_DIR([config])
> AM_INIT_AUTOMAKE([1.9 foreign])
> AC_CONFIG_SRCDIR([main.cpp])
> AC_CONFIG_HEADER([config.h])
> 
> dnl AC_CHECK_LIB([BOGUS], [dummy])
> 
> if test "x$TEST" = "xtrue"; then
>   AC_MSG_RESULT([The test is true])
>   AC_CHECK_LIB([BOGUS], [dummy])
> else
>   AC_MSG_RESULT([The test is false])
>   AC_CHECK_LIB([BOGUS], [dummy])
> fi

The problem here is that AC_CHECK_LIB internally uses some other macros,
and some of those macro require other macros to be called before that.
Autoconf has a mechanism to ensure those requirements are met (once):
AC_REQUIRE.  The mechanism works a bit differently from what you would
expect, though: if you call a macro M1, and that requires another macro
M2, Autoconf checks if it has already expanded M2 anywhere; if not, it
expands M2 right before M1.  So that will lead to
  if ... then
   ...
   expansion of M2
   expansion of AC_CHECK_LIB
  else
   ...
   expansion of AC_CHECK_LIB
  fi

See how the fact that M2 will be expanded only once interacts badly with
shell conditionals?

With the next Autoconf version, there will be a way out that is a bit
cleaner:

  AS_IF([test "x$TEST" = xtrue],
    [AC_MSG_RESULT([The test is true])
     AC_CHECK_LIB([BOGUS], [dummy])],
    [AC_MSG_RESULT([The test is false])
     AC_CHECK_LIB([BOGUS], [dummy])])

as that will then lead to
  expansion of M2
  if ... then
    ...
    expansion of AC_CHECK_LIB
  else
    ...
    expansion of AC_CHECK_LIB
  fi

AS_IF already exists in Autoconf 2.59, but only in 2.60 will it have the
property that it will cause expansion of required macros from macros
inside its arguments to happen _before_ the expansion of the if clause.

*snip*
> AC_CONFIG_FILES([Makefile])
> AC_PROG_CXX
> AC_OUTPUT

The checks for compilers should be done early in the configure.ac
script.  I think a suggested order is mentioned in the manual, though.

There is another potential issue here: do you want the library tests to
be done with the C or the C++ compiler?  If the former, you should
  AC_PROG_CC
  AC_PROG_CXX
  
before doing the library checks, if the latter, you should do at least
  AC_PROG_CXX
  AC_LANG([C++])

but for some other tests a C compiler may be required anyway, so it's
prudent to check for it as well.

> A workaround is to put an AC_CHECK_LIB before the conditional block, for 
> instance by uncommenting the dnl-line in the script above.

Yep.  But you don't need that anymore now.

> A note about this in the manual could perhaps be an easy fix to the 
> problem.

Well, it's definitely not easy to see all of this unless you read the
whole manual and also have some experience, I agree.  OTOH, if you had
followed the order of
  info Autoconf "configure.ac Layout"

this wouldn't have hit you.  :-)

Cheers,
Ralf




reply via email to

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