[Dune] dune m4 tests

[Markus Blatt]

Hi,

On Thu, Aug 26, 2010 at 12:10:21PM +0200, Carsten Gräser wrote:
> we just encountered a problem with the new boost test in dune-common
> related to the fact that we have our own copy of the AX_BOOST_BASE
> test from the autoconf archive. In this context several general
> questions/problems arise:
> 
> 1) Which test is used if it is defined twice (in m4-files with
>    possibly different names)?

Apparently the order is somewhat unpredictable (At least it is not
coherent with the dependency tree of the modules.

On my system dune-autogen for dune-pdelab-howto is called like this
dune-autogen /home/mblatt/src/dune/current/dune-richards \
/home/mblatt/src/dune/current/dune-amg-test \
/home/mblatt/src/dune/current/dune-grid \
/home/mblatt/src/dune/current/dune-localfunctions \
/home/mblatt/src/dune/current/dune-common \
/home/mblatt/src/dune/current/dune-pdelab-howto \
/home/mblatt/src/dune/current/dune-pdelab \
/home/mblatt/src/dune/current/dune-istl

IMHO this is a bug! I would propose to build the dependency tree and
then prepend all m4 subdirectories to the search path.

Still if we provide a macro in the specified search path it supersedes
the one in the default search path

> 2) Does the dune-istl test called from our module use the dune-common
>    version of the boost test?

See above. If you are lucky, yes. If it uses the default it is not a
problem as long as boost is installed.

> 3) Does our own call to the test use our version of the boost test?

Dito

> 4) Which version is used if you have installed some autoconf-archive package?
> 

One of the ones in the dune modules.

> 5) Is it possible to warn for multiple definitions of tests?
>

Don't know
 
> 6) Will dune-istl work if we (successfully) test for an older boost
>    version then the one required in dune-istl?

I do not require the test, but run it again. Therefore I would guess
it is not a problem.

> 7) Currently the dune packages conflict we the autoconf-archive package
>    due to the copies of tests.

Do they? Not on my system. I can imagine that there are conflicts if you have copied
ax_boost_base to your module's m4-directory.

> 
> One possible clean solution to avoid all these problems is attach
> a dune prefix to each test and result (automake variables and defines)
> in the dune core modules.
> 

mblatt at catania:~/src/dune/current$ diff dune-common/m4/ax_boost_base.m4 /usr/share/aclocal/ax_boost_base.m4
205c205
<			AC_MSG_NOTICE([[We could not detect the boost libraries (version $boost_lib_version_req_shorten or higher). If you have a staged boost library (still not installed) please specify \$BOOST_ROOT in your environment and do not give a PATH to --with-boost option.  If you are sure you have boost installed, then check your version number looking in <boost/version.hpp>. See http://randspringer.de/boost for more documentation.]])
---
>			AC_MSG_ERROR([[We could not detect the boost libraries (version $boost_lib_version_req_shorten or higher). If you  have a staged boost library (still not installed) please specify \$BOOST_ROOT in your environment and do not give a PATH to --with-boost option.  If you are sure you have boost installed, then check your version number looking in <boost/version.hpp>. See http://randspringer.de/boost for more documentation.]])


The only difference between the two is, that if boost is not installed
using my test configure runs through. Using the official test
configure aborts. The latter is not what I want. Having boost
installed the outcome is the same, anyway.

Therefore changing all the variables and defines does not seem
practicable for me. Instead we could just rename the current test
macro in dune-common and create a new one with the original name that
aborts configure if boost is not installed.

BTW what was the error message exactly?

Markus