<div dir="ltr"><div><div><div class="gmail_extra"><div><div><div>Hey Martin,<br><br></div>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.<br><br>What is config.h?<br>config.h is a mechanism to pass information (in the form of preprocessor defines) from the buildsystem to the compiler.<br></div><div>These are mainly the results of configure time checks, which are needed in Dune to work properly in the detected environment.<br></div><div>Example: Dune performs (or performed previously) checks at configure time, whether the given compiler supports certain C++<br></div><div>features and exports the results through config.h. Neither the dune libraries nor any application using Dune headers can be<br></div><div>built successfully without this information, as some fallback implementations were needed for missing language features.<br></div><div>The only real technical alternative would be to pass all flags separately to the compiler, which is not really suitable for a project<br></div><div>the size of Dune.<br></div><div><br>How do I use config.h?<br>From a user perspective there is really only one thing you need to know about config.h:<br></div>At the beginning of each of your .cc files, write #include"config.h" as the very first line.<br></div><div>This way you make all the buildsystem information available to the Dune headers.<br><br></div><div>How do I add information to config.h?<br></div><div>Each Dune module (even freshly generated ones by the duneproject script) provides a config.h.cmake<br></div><div>This file defines a template for the snippet of config.h containing information on your module. The template<br></div><div>is resolved by the cmake command configure_file. You might want to read up the documentation at<br></div><div>cmake --help-command configure_file<br></div><div>to understand how this happens.<br></div><br></div><div class="gmail_extra">How is the final config.h generated?<br></div><div class="gmail_extra">I will spare you those details that are too technical or magic, but the procedure is generally as follows:<br></div><div class="gmail_extra">The config.h.cmake snippets from your module and from all required/suggested modules are pasted<br></div><div class="gmail_extra">into one large template (guaranteeing that the snippets of all requirements of module are included before<br></div><div class="gmail_extra">the module snippet is). This large template is used to generate a config.h with the currently set variables in CMake.<br></div><div class="gmail_extra">Important fact: Each Dune module has its own config.h and you always include the one from your own project,<br></div><div class="gmail_extra">as it contains all information from all required modules already.<br></div><br></div>I hope this kind of general information helps. Sorry, that I do not really answer your questions. But from what I understand,<br></div><div>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<br><br></div><div>Best,<br></div><div>Dominic<br></div><div><div><br><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 12, 2016 at 4:28 PM, Martin Rückl <span dir="ltr"><<a href="mailto:mrueckl@physik.hu-berlin.de" target="_blank">mrueckl@physik.hu-berlin.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Hi Christoph,<br>
</div><span class="">
<blockquote type="cite">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?
</blockquote></span>
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:<br>
<ol>
<li>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. <br>
</li>
<li>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.</li>
<li>There also might be configuration variables, which impact
both, interface and compiled library.<br>
</li>
</ol>
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...<br>
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).<br>
Same for #3 but the user is not supposed to change them, since this
might break header<->library compatibility.<br>
<br>
One example for #2 are the <font face="monospace">DUNE_VERSION_NEWER_REV(DUNE_GRID,2,4,0)</font>
macros which are e.g. used in <font face="monospace">alugrid/geometry.hh</font>.
Here the interface depends on a variable set in the config.h files,
i.e. the <font face="monospace">DUNE_***_VERSION</font> stuff.<br>
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.<br>
For 10 libraries like dune, would i have to include 10 different
config.h files, one for each dependency?<br>
I realized that dune installs <font face="monospace">config.h.cmake</font>
files in <font face="monospace">prefix/share/dune-module/config.h.cmake</font>.
But those files seem incomplete (e.g. <font face="monospace">#define
DUNE_COMMON_VERSION_MAJOR ${DUNE_COMMON_VERSION_MAJOR}</font>)<br>
Further, I have no idea how they are supposed to be used :-(<br>
For the reference, I just had a short look to eigen: they define <font face="monospace">EIGEN_***_VERSION 3</font> in an installed header
file (<font face="monospace">Eigen/src/Core/util/Macros.h</font>).<br>
<br>
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)<br>
<br>
HtH Martin<br>
</div>
<br>_______________________________________________<br>
Dune mailing list<br>
<a href="mailto:Dune@dune-project.org">Dune@dune-project.org</a><br>
<a href="http://lists.dune-project.org/mailman/listinfo/dune" rel="noreferrer" target="_blank">http://lists.dune-project.org/mailman/listinfo/dune</a><br>
<br></blockquote></div><br></div></div></div></div>