autoconf
[Top][All Lists]
Advanced

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

Re: Problem with macro inside inactive conditional changing autoconf beh


From: Ralf Wildenhues
Subject: Re: Problem with macro inside inactive conditional changing autoconf behavior
Date: Sun, 31 Jan 2010 15:54:36 +0100
User-agent: Mutt/1.5.20 (2009-10-28)

Hello Douglas,

* Dr. Douglas C. MacKenzie wrote on Fri, Jan 29, 2010 at 09:29:31PM CET:
> I am having trouble with a configure.ac file after upgrading from
> libtool 1.5 to 2.2.6 as part of moving from Fedora 10 to Fedora 12.
[...]
> > AC_ARG_VAR(COMPILER, "Use COMPILER=MSC to compile for WIN32 using Microsoft 
> > C++ compiler.\nUse COMPILER=GCC to comnpile using GNU tools (default).\n")
> > if test "x$COMPILER" = "xMSC"; then
> >    echo "Compiling using Microsoft C++ compiler"
> > dnl    AC_LIBTOOL_WIN32_DLL
> >     AC_SUBST(BUILD_WINDOWS, true)
> > else
> >    echo "Compiling using GNU tools"
> >    AC_SUBST(AM_CXXFLAGS, "-Wall")
> > fi
[...]
> The commands:
>    autoreconf --force --install
>    ./configure
>    ./libtool --features
> 
> generate:
>    host: x86_64-unknown-linux-gnu
>    enable shared libraries 
>    enable static libraries
> 
> But, If I change the "dnl    AC_LIBTOOL_WIN32_DLL" line to   "
> AC_LIBTOOL_WIN32_DLL"
> 
> The commands:
>    autoreconf --force --install
>    ./configure
>    ./libtool --features
> 
> Now generate:
>    host: 
>    disable shared libraries
>    enable static libraries

That's weird.  Can you post the configure output in the second case?
This is a Libtool issue, not an Autoconf one.

That said, it should work to just move the AC_LIBTOOL_WIN32_DLL outside
of the if clause, so it is called unconditionally.  Another thing you
can try is
  AS_IF([CONDITION],
        [IF-TRUE],
        [IF-FALSE])

with Autoconf 2.60 or newer.

Another thing to note is that the AC_SUBST macro typically expands to no
shell code at all, and it anyway has unconditional effect, so
  if $foo; then
    AC_SUBST([bar])
  fi

will unconditionally substitute @bar@, and likely cause a shell syntax
error.

Cheers,
Ralf




reply via email to

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