Always include debug symbols in the build, and strip them to a separate
file after compiling. The GNU debugger will automatically pick up the
external debug symbols due to a link we put in the executable.
Having debug symbols do not affect the level of optimization in the GNU
toolchain.
If the program is built out-of-source-tree then the configuration file
(which is generated and not part of the source) will not be available
relative to the source code file.
Search for known headers and library files that indicates that DUNE is
available on the system, and setup compiler and linker variables.
Unfortunately, this module has hard-coded some knowledge of the
dependencies on other modules, and knowledge of which symbols that
should be defined. This information must be revised whenever a new
version of DUNE is released, because it is hard and error-prone to
infer this automatically.
As for the name of the modules, see the comment by mblatt at 2012-05-22
in the thread about CMake evaluation in the DUNE user forum:
<http://www.dune-project.org/flyspray/index.php?do=details&task_id=1000>
Search for modules in this library in the same style as Boost; by
specifying a list of components. If all on the list is present, then
a list of libraries to link with, is returned.
BOOST_TEST_DYN_LINK must be defined if you are *building* Boost::Test as
a shared object, and the client programs must also include this option
when they use the header files, to link to it correctly.
Normally a package returns a set of standard variables such as
Xxx_INCLUDE_DIRS. Adding this to a list that is collected for the
project amounts to a bunch of boilerplate which can rather be
encapsulated in a macro.
We want to compile with the -std=c++0x since DUNE uses this settings and
we need to use the same ABI as that one if we are going to link with it.
Find module is a copy of the one in cmake/modules in (the cmake branch of)
dune-common.
Some files are distributed with the source, but does not end up in the
final shared object. These files are captured by the glob, so we have
to remove them afterwards. (There are fewer of these files than
explicitly list all files that should be included in the build).
A fundamental problem with the configure_file() command is CMake is that
the author of the template file config.h.in must know which variables
all modules need to have defined, and this is not easily communicated.
The idea behind this function is: Each Find-module can return a list of
variables that it has filled with probed values, and that should be
written to config.h, which is again included by the header file of this
module.
Each project thus defines its own config.h file, which is common between
all module's headers.
The existing description did not properly account for ERT (or, more
appropriately, the "libecl" part of ERT) being installed in a
non-default location (e.g., somewhere below ${HOME}).
As EclipseGridParser.hpp declares various ERT-dependent types and
functions if a build configuration supports ERT (activated by the
`--with-ert' configure option), we need a proper include path to
reference the ERT headers. The fix is simple--just insert the
$(ERT_CPPFLAGS) into the already existing $(AM_CPPFLAGS).
The existing code compared the output of data->size(), which is a
std::vector<double>::size_type (typically std::size_t) and therefore an
unsigned integer type to the number 'grid.number_of_cells' which is a
(signed) 'int'. This leads to an annoying warning when increasing the
warning level in GCC.
While here, also insert code to verify that the 'stride' is a positive
number lest the subsequent assignment loop reference (*data) elements
out of bounds.
Should now be in sync with cfs_tpfa_residual C interface. Simple well
gravity model implemented.
More flexibility in well gravity models would be a natural future extension.
We previously ignored effects of gravity in the calculation of the well
connection fluxes (i.e., perforation fluxes). This commit includes
those effects where appropriate.
