[Dune] dune m4 tests

[Jö Fahlke]

Am Thu, 26. Aug 2010, 12:10:21 +0200 schrieb Carsten Gräser:
> 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)?

The program that decides that is aclocal.  According to "info aclocal", there
is a search path:

| Any extra directories specified using `-I' options (*note aclocal
| Options::) are _prepended_ to this search list.  Thus, `aclocal -I /foo
| -I /bar' results in the following search path:
|
|   1. `/foo'
|
|   2. `/bar'
|
|   3. ACDIR-APIVERSION
|
|   4. ACDIR

ACDIR-APIVERSION is /usr/share/aclocal-1.11 in my case, and ACDIR is
/usr/share/aclocal.

The info page is very comprehensive in describing how the directories are
ordered within the search path, but unfortunately fails to mention whether
earlier or later entries in the search path take precedence.  However, the
ordering as given above only makes sense if earlier directories take
precedence.

I guess the answer to your question is: aclocal selects the test from the
directory appearing earlier in its serch path.  If both macros are defined in
different files inside the same directory, the behaviour is probably
unspecified, so don't do that.

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

If both tests have the same name, both calls will use the same test (unless
acloal or autoconf give an error because of a duplicate definition).  As to
which test is used, see the answer to 1).

If both tests have different names you may still get problems: it is likely
that the use the same shell variables while configure runs, or uses the same
defines or substitutions.

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

autoconf-archive installs its .m4-file into ACDIR, so they are only taken as a
last resort.

> We assume that in this situation the "correct"/expected test is not
> always used. This leads to:
> 
> 5) Is it possible to warn for multiple definitions of tests?

I don't think so, at least not out of the box.  You may be able to achieve
something using autom4te, but that is probably rather tricky.

> Even if the "correct" version is used in all above cases further
> problems will occure:
> 
> 6) Will dune-istl work if we (successfully) test for an older boost
>    version then the one required in dune-istl?

"Correct version beeing used" requires that the tests have different names,
and that their shell variables and defines and substitution names don't
interfere.  We have to consider several cases:

 * your test finds boost, istl-test finds the same boost:
   Everything should work.

 * your test finds boost, istl-test finds a different boost:
   At compile time one boost will end up earlier in the include path and will
   take precedence.  At link time you will probably get an error.
   This can happen if the system or environment is misconfigured, or if
   inconsistent options are given to configure.

 * your test finds boost, istl-test does not:
   Everything should work, although istl may not include the functionality it
   requires boost for.

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

That should not be neccessary.  dunecontrol calls aclocal with the
dune-m4-directories given as arguments to -I options, so those directories
take precedence over the tests provided by autoconf-archive.

> 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.

If we simply include an unmodified copy of the autoconf-archive file
containing the test there is no need to rename the test.  If we need to make
modification, and decide against pushing them upstream, then we definitly
should rename the test, the shell variables it uses, and its output names
(defines, substitutions, etc.).  It may be a good idea to accept the same
configure options as the origninal test however (--with-boost=...), but may
not always be possible without potential for conflicts.

If modifications need to be made, it is probably best to include the test from
autoconf-archive unmodified, and AC_REQUIRE it from a Dune-wrapper, i.e.

AC_DEFUN([DUNE_BOOST], [
  AC_REQUIRE([AX_BOOST])
  # do some additional magic here
])

Bye,
Jö.

-- 
featured product: Debian GNU/Linux - http://www.debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20100827/9c596a70/attachment.sig>