[Dune] dune & cmake

[Ansgar Burchardt]

Hi Dominic,

Dominic Kempf <dominic.r.kempf at gmail.com> writes:
> I still think this discussion is a huge misunderstanding. I will try to sum
> up some information on config.h to shed some light on the issue, maybe also
> for future reference.

I think the confusion stems from DUNE using `config.h` in a way that is
not common (and arguably not correct): usually `config.h` is a private
include that only affects the *current* projects configuration. It is
*not* supposed to configure other modules.

However DUNE does things differently: `config.h` in dune-myapplication
also configures dune-common, dune-grid and other modules. This forces
dune-myapplication to use DUNE's build system: there is no other way to
generate the correct `config.h`.

This use can also introduce subtle bugs when the configuration differs
when building different modules: suppose dune-A has a class

  struct MyThing {
  #if HAVE_MPI
    int rank;
  #endif
    int something;
  };

and a function

  int get_something(MyThing& thing) { return thing.something; }

that gets build into libduneA with HAVE_MPI false.

Now consider dune-B defining HAVE_MPI to true and this code in dune-B:

  MyThing thing;
  auto x = get_something(thing);

But now get_something() will likely return the `rank` variable instead
of `something` as the size of MyThing is different.

Considering DUNE uses ENABLE_MPI to configure MPI support on a
per-target base and this doesn't affect library dependencies, this could
happen in real life more often if people would write less header-only
modules.

If each DUNE module had its own configuration this wouldn't happen:
dune-A would rely on DUNE_A_HAVE_MPI in dune/a/config-dune-a.hh which
would not change depending on the configuration of dune-B.

It would also mean that the configure time checks for dune-A wouldn't
have to run again when building dune-B (as config-dune-a.hh is already
there). This also implies you could use dune-A more easily from other
build systems, provided there is also a way to specify what libraries
need to be linked.

However it means more work: each use of HAVE_MPI in dune-B would have to
be replaced by DUNE_B_HAVE_MPI or, in some cases, by DUNE_A_HAVE_MPI (or
by another module's HAVE_MPI).

Ansgar