<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Christoph,<br>
</div>
<blockquote cite="mid:570C8232.7010201@iws.uni-stuttgart.de"
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>
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>
</body>
</html>