[Dune] Error building dune-istl: #if with no expression

[Bård Skaflestad]

On Fri, 2012-07-06 at 13:28 +0200, Bård Skaflestad wrote:
> On Fri, 2012-07-06 at 13:09 +0200, Lars Vingli Odsæter wrote:
> > In file included from ../../../dune/istl/gsetc.hh:11,
> >                  from example.cc:23:
> > ../../../dune/istl/multitypeblockvector.hh:4:15: error: #if with no expression
> 
> [etc]
> 
> See FlySpray issue 1145
> (http://www.dune-project.org/flyspray/index.php?do=details&task_id=1145)
> 
> You may want to stick to using
> 
>       * dune-common at 6479
>       * dune-istl at 1491 (especially)
>       * dune-grid at 7672 (possibly)

First of all: Thank you, Christian, for applying the patch in FS-1145.

I guess I should have been a little more explicit about what I referred
to when answering the original question, though.  I was thinking more
about the comment towards the end of FS-1145 than the actual patch
itself.  Specifically, the issue about a (possible) race condition in
the definition of the DUNE_BOOST_BASE macro.

According to the Autoconf documentation, the value that gets set for a
particular symbol (say "HAVE_BOOST") is the *last* definition of that
symbol in an AC_DEFINE invocation.  Now, DUNE_BOOST_BASE more or less
looks like the following:

    AC_DEFUN([DUNE_BOOST_BASE],
    [
       invoke AX_BOOST_BASE  (sets HAVE_BOOST using AC_DEFINE
                              if successful)

       if Boost is found; then

         AC_DEFINE(HAVE_BOOST, [ENABLE_BOOST], ...)
         BOOST_CPPFLAGS="$BOOST_CPPFLAGS -DENABLE_BOOST"
         AC_SUBST(BOOST_CPPFLAGS)

       else

         take appropriate action

       fi
    ])

When this macro is processed using Autoconf 2.59 however (and my crystal
ball tells me that in Lars' case it is), there is some error that leads
to the HAVE_BOOST symbol being defined, by the resulting configure
script, to the output of the AX_BOOST_BASE macro rather than
[ENABLE_BOOST] as intended.  In all likelihood, this effect is the
result of a programming error in (the ancient) Autoconf 2.59, because
the DUNE_BOOST_BASE macro uses only documented behaviour of AC_DEFINE as
far as I can tell.

At first I thought it might be a result of lack of parameter quoting in
DUNE_BOOST_BASE's invocations of AC_DEFINE and AC_SUBST, but switching
to

        AC_DEFINE([HAVE_BOOST], [as before])
        AC_SUBST([BOOST_CPPFLAGS])

does not change the behaviour of the generated configure script.


Sincerely,
-- 
Bård Skaflestad <Bard.Skaflestad at sintef.no>
SINTEF ICT, Applied Mathematics