[Dune] dune m4 tests

[Carsten Gräser]

Am 26.08.2010 15:04, schrieb 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.
Dune-istl requires a special version of boost. If it is not found
HAVE_BOOST is not defined. If another module wants to use
boost but tests for an older version afterwards it may succed
with HAVE_BOOST defined although the boost is not new enought
for dune-istl.

> 
>> 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.
I didn't try this. Oliver said that the packages have a conflict.

> 
>>
>> 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.
Even if a test in dune-common is an identical copy it does not
neccessary behave the same than a copy (from of a different version)
in another module or an installed version of the test.

> 
> 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.
> 
Having a unique name would be a first step. But it does not solve
the version issue.

> BTW what was the error message exactly?
It was something like 'Could not link against -lGL'.

As far as I know from debugging the configure script build from an
old (buggy) version of the boost test the reason is that '-lGL' is
just a relict of a previous OpenGL test and not related to the error
in any way. So not only the fact that the test aborts is a bug.
Even the error message itself is buggy.

Regards
Carsten


-- 
----------------------------------------------------------------------
Carsten Gräser           | phone: +49-30 / 838-75349
Freie Universität Berlin | fax  : +49-30 / 838-54977
Institut für Mathematik  | email: graeser at math.fu-berlin.de
Arnimallee 6             |
14195 Berlin, Germany    | URL  : http://page.mi.fu-berlin.de/graeser
----------------------------------------------------------------------