[Dune] dune & cmake

[Dominic Kempf]

Hey Martin,

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.

What is config.h?
config.h is a mechanism to pass information (in the form of preprocessor
defines) from the buildsystem to the compiler.
These are mainly the results of configure time checks, which are needed in
Dune to work properly in the detected environment.
Example: Dune performs (or performed previously) checks at configure time,
whether the given compiler supports certain C++
features and exports the results through config.h. Neither the dune
libraries nor any application using Dune headers can be
built successfully without this information, as some fallback
implementations were needed for missing language features.
The only real technical alternative would be to pass all flags separately
to the compiler, which is not really suitable for a project
the size of Dune.

How do I use config.h?
>From a user perspective there is really only one thing you need to know
about config.h:
At the beginning of each of your .cc files, write #include"config.h" as the
very first line.
This way you make all the buildsystem information available to the Dune
headers.

How do I add information to config.h?
Each Dune module (even freshly generated ones by the duneproject script)
provides a config.h.cmake
This file defines a template for the snippet of config.h containing
information on your module. The template
is resolved by the cmake command configure_file. You might want to read up
the documentation at
cmake --help-command configure_file
to understand how this happens.

How is the final config.h generated?
I will spare you those details that are too technical or magic, but the
procedure is generally as follows:
The config.h.cmake snippets from your module and from all
required/suggested modules are pasted
into one large template (guaranteeing that the snippets of all requirements
of module are included before
the module snippet is). This large template is used to generate a config.h
with the currently set variables in CMake.
Important fact: Each Dune module has its own config.h and you always
include the one from your own project,
as it contains all information from all required modules already.

I hope this kind of general information helps. Sorry, that I do not really
answer your questions. But from what I understand,
you are trying to work around using the Dune build system, and the only
support I can give in that case, is to convince you not to . :D

Best,
Dominic

On Tue, Apr 12, 2016 at 4:28 PM, Martin Rückl <mrueckl at physik.hu-berlin.de>
wrote:

> 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
>
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20160412/fb17063a/attachment.htm>