[Dune] [Build system] Is it OK to invoke the DUNE_ADD_MODULE_DEPS macro directly?

[Bård Skaflestad]

Dear Dune,

Whilst splitting our module (dune-cornerpoint) up into a few sub-modules
we have encountered a bump in the road.  The original module depends on
a few external libraries (notably Boost) for even its most basic
functionality.  This dependency must be conveyed transitively to the
clients of our module.  If Boost is in a standard location such
as /usr/include/boost everything is fine.  However, if Boost is located
elsewhere (e.g., in /work/include/boost for the headers and /work/lib64
for the compiled libraries), then client builds fail at the configure
stage.

I have tentatively tracked the configure failure down to the
DUNE_CORNERPOINT_CHECK_MODULE macro in the
dune-cornerpoint/m4/dune_cornerpoint.m4 file getting insufficient system
information concerning the exact location of Boost.  Reviewing the M4
infrastructure in dune-common/m4, and especially the dune.m4 file within
said directory, it appears that the DUNE_ADD_MODULE_DEPS macro will go
at least some way towards support for arbitrary module dependencies.

Specifically, inserting the macro call

        # Add Boost support to module dependencies
        DUNE_ADD_MODULE_DEPS([DUNE_CORNERPOINT],dnl
                             [DUNE_CORNERPOINT],dnl
          [$BOOST_CPPFLAGS],dnl
          [$BOOST_LDFLAGS],dnl
          [[$BOOST_DATE_TIME_LIB]dnl
           [$BOOST_FILESYSTEM_LIB]dnl
           [$BOOST_SYSTEM_LIB]])dnl

into our AC_DEFUN([DUNE_CORNERPOINT_CHECKS]) definition allows our
client builds to succeed.  My question, then, is if it is officially
sanctioned within the Dune build system for individual modules to invoke
DUNE_ADD_MODULE_DEPS directly or if this macro is considered an
implementation detail of DUNE_CHECK_MODULES.  As far as I can tell, the
buildsystem.pdf document is silent on the matter.


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