[dune-fem] GridSelector for CMake

[Martin Nolte]

Dear all,

as promised, I ported my (pyton-based) grid selection script for use with 
CMake to dune-fem in a feature branch (grid-selector) for further evaluation.

To reduce work on my side, I only ported Robert's new discrete function test 
to work with this grid selection mechanism. A small manual is included in the 
commit message.

Obviously, this stuff is completely new and rather untested (except by 
myself). For example, I doubt that installation will work in the current 
state. However, it should be sufficient for testing and should illustrate the 
impact on the personal work flow.

The basic idea is to generate a header file containing the grid definition and 
all necessary includes. The user simply runs a small tool (dune-grid-select), like

./dune-grid-select YaspGrid dimgrid=2

and magically a header file gridselector.hh is generated.

The script itself does not depend on our build system. However, some kind of 
data base holding all possbile grid definitons is required. For modularity 
reasons, this data base is distributed over several "include"-files. Like a 
compiler, the script then requires some '-I <file>' arguments to find the grid 
definitions.

To make life easier, the '-I <file>' arguments are provided by the build 
system in small wrapper script, the above-mentioned dune-grid-select. This is 
appropriate, as we need support from the build system, anyway, to ensure our 
executables correctly depend on the generated header file.

In contrast, the autotools mechanism has one header (now config.h) containing 
all potentially used definitions (and their includes). Here, too, the build 
system is used to build up the data base of all possible grid definitions (the 
list in config.h). The desired grid is then chosen by preprocessor macros, 
which can be overloaded on the make command line.

While there have been many discussions on overloading the command line 
arguments of make within a CMake environment, it is my understanding that this 
is against the CMake philosophy (the pros and cons of which I do not want to 
discuss, here). The above-suggested method, on the other hand, generated clear 
rules on building a single executable. If you never call the dune-grid-select 
script by hand, you have a clear build process. On the other hand, if you do 
call the script, you change one file in the dependency chain and a subsequent 
'make' will rebuild all dependent files (using the new grid).

To be fair: I have not tested this method with any other backend that GNU 
make. It is absolutely possible that other dependency tracking systems do not 
allow manipulation of intermediate files (like gridselector.hh).

Finally, I'd like to point out that the use of python is pure convenience on 
my side. The script could be reimplemented in C++ to avoid this dependency.

Have fun evaluating!

Best,

Martin



-- 
Dr. Martin Nolte <nolte at mathematik.uni-freiburg.de>

Universität Freiburg                                   phone: +49-761-203-5630
Abteilung für angewandte Mathematik                    fax:   +49-761-203-5632
Hermann-Herder-Straße 10
79104 Freiburg, Germany