[Dune-devel] [Dune] dune & cmake

[Martin Nolte]

Hi Ansgar,

this seems more like a developer conversation, so I migrate this discussion there.

Your basic argument is correct. In a usual C++ code, the header files should
not require all those configuration flags. Instead, they should be used to
build the library correctly.

This directly refers to the use/enable-trick, which we are trying to abandon.
Once this is achieved, we can migrate some of the checks into the lib and keep
them in the private section of the modules. Setting HAVE_UMFPACK in user code
is definitely not necessary, but can be put into our libs.

Nevertheless, we are talking a template code. For example, if I wanted to  put
the HAVE_MPI switch for SPGrid into the lib, I would have to ask you for all
ctype/dim combinations you would ever want to use it with. It also means that
some inline methods can no longer stay inline but must go into the lib, a
negative performance impact unless you enable LTO.

As a result, I think we cannot completely avoid some preprocessor conditions
in our headers. However, this does not mean that we cannot try to minimize
them. We could even provide a list of preprocessor config switches that we
actually need.

Best,

Martin

On 04/19/2016 11:32 AM, Ansgar Burchardt wrote:
> 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
> 
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune
> 

-- 
Dr. Martin Nolte <nolte at mathematik.uni-freiburg.de>

Universität Freiburg                                   phone: +49-761-203-5630
Abteilung für angewandte Mathematik                    fax:   +49-761-203-5632
Hermann-Herder-Straße 10
79104 Freiburg, Germany