[Dune] dune & cmake

[Martin Rückl]

Hi Christoph,
> What's your problem with the config.h? That the canonical way to pass 
> configure results. Why should someone want to hide that and make it 
> less discoverable? 
I don't have any problems with dune using a config.h. I'm just having a 
hard time understanding the meaning of config.h. I'll try to explain the 
use cases i see:

 1. config.h is only required for building the library and will not be
    exposed to the user (i.e. will not be installed). That requires that
    the library interface does not depend on the config.h file. This
    implies, that usage of #defines from the config.h files may only
    occur within the libraries compiled .cpp files.
 2. The interface itself depends on the variables set during
    configuration stage. Since heavy use of template tends to result in
    code moved from .cpp to .hpp files, this case is realistic.
 3. There also might be configuration variables, which impact both,
    interface and compiled library.

I think #1 makes sense and is the original intention of config.h files, 
at least thats what i got from various posts at SO (Please tell me if 
wrong!). The user of a library doesn't need to know about the configure 
internals of the library. He doesn't have to include it in any of his 
files. If #1 isn't the intended usage, then the remaining part of this 
mail is obsolete...
For variables of type #2, I would assume that they have reasonable 
default values somewhere in the installed header files. Then the user 
can still change the interface by setting his own defines (if he knows 
what he is doing).
Same for #3 but the user is not supposed to change them, since this 
might break header<->library compatibility.

One example for #2 are the DUNE_VERSION_NEWER_REV(DUNE_GRID,2,4,0) 
macros which are e.g. used in alugrid/geometry.hh. Here the interface 
depends on a variable set in the config.h files, i.e. the 
DUNE_***_VERSION stuff.
Hence, to use the configuration dependent interface, I have to include 
the alugrid/config.h in my own *.cpp files. Obviously this isn't a big 
deal for small projects which only depend on dune. But what happens for 
more complicated setups.
For 10 libraries like dune, would i have to include 10 different 
config.h files, one for each dependency?
I realized that dune installs config.h.cmake files in 
prefix/share/dune-module/config.h.cmake. But those files seem incomplete 
(e.g. #define DUNE_COMMON_VERSION_MAJOR ${DUNE_COMMON_VERSION_MAJOR})
Further, I have no idea how they are supposed to be used :-(
For the reference, I just had a short look to eigen: they define 
EIGEN_***_VERSION 3 in an installed header file 
(Eigen/src/Core/util/Macros.h).

I am aware that the change from autotools to cmake isn't that long ago, 
and i REALLY appreciated this transition. Please do not understand this 
mail as: "your buildsystem is bullshit" I merely try to describe my own 
thoughts! I just want to help/understand! Maybe my arguments are helpful 
for any of your further discussions on the buildsystem topic. (I 
somewhere read that 3.0 might introduce some other changes :P)

HtH Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20160412/d60657da/attachment.htm>