+The default configuration should be ok for most usages, but if you
+need to change something, there is several ways to do so. First, you
+can use environment variables. For example, you can change the used
+compilers by issuing these commands before launching cmake:
+
+@verbatim
+export CC=gcc-4.4
+export CXX=g++-4.4
+@endverbatim
+
+Note that other variables are available, such as CFLAGS and CXXFLAGS to add
+options for respectively the C compiler and the C++ compiler.
+
+Another way to do so is to use the -D argument of cmake as follows.
+Note that the terminating dot is mandatory (see @ref
+install_cmake_outsrc to understand its meaning).
+
+@verbatim
+cmake -DCC=clang -DCXX=clang++ .
+@endverbatim
+
+Finally, you can use a graphical interface such as ccmake to change
+these settings. Simply follow the instructions after starting the
+interface.
+
+@verbatim
+ccmake .
+@endverbatim
+
+\subsubsection install_cmake_list SimGrid compilation options
+
+In addition to the classical cmake configuration variables, SimGrid
+accepts several options, as listed below.
+
+ @li <b>CMAKE_INSTALL_PREFIX</b> (path): Where to install SimGrid
+ (e.g. /usr/local or /opt).
+
+ @li <b>enable_compile_optimizations</b> (ON/OFF): request the
+ compiler to produce efficient code. You want to activate it,
+ unless you want to debug SimGrid itself (as efficient code may
+ be appear mangled to the debuggers).
+
+ @li <b>enable_debug</b> (ON/OFF): disable this if simulation speed
+ really matters to you. All log messages of gravity debug or
+ below will be discarded at compilation time. Since there is
+ quite a bunch of such log messages in SimGrid itself, this can
+ reveal faster than discarding them at runtime as usually. But of
+ course, it is then impossible to get any debug message from
+ SimGrid if something goes wrong.
+
+ @li <b>enable_msg_deprecated</b> (ON/OFF): enable this option if
+ your code used a feature of Simgrid that was dropped or modified
+ in recent releases of SimGrid. You should update your code if
+ possible, but with this option, SimGrid will try to emulate its
+ old behavior.
+
+ @li <b>enable_model-checking</b> (ON/OFF): Only enable this if you
+ actually plan to use the model-checking aspect of SimGrid. This
+ mode of execution is still under heavy work, but it should be
+ rather usable now. Be <b>warned</b> that this option will hinder
+ your simulation speed even if you simulate without activating
+ the model-checker. We are working on improving this situation.
+
+ @li <b>enable_compile_warnings</b> (ON/OFF): request the compiler to
+ issue error message whenever the source code is not perfectly
+ clean. If you develop SimGrid itself, you must activate it to
+ ensure the code quality, but as a user, that option will only
+ bring you issues.
+
+ @li <b>enable_lib_static</b> (ON/OFF): enable this if you want to
+ compile the static library (but you should consider enjoying
+ this new century instead).
+
+ @li <b>enable_maintainer_mode</b> (ON/OFF): you only need to set
+ this option if you modify very specific parts of SimGrid itself
+ (the XML parsers and other related elements). Adds an extra
+ dependency on flex and flexml.
+
+ @li <b>enable_tracing</b> (ON/OFF): disable this if you have issues
+ with the tracing module. But this module is now very stable and
+ you really should try to enjoy this beauty.
+
+ @li <b>enable_smpi</b> (ON/OFF): disable this if you have issues
+ with the module allowing to run MPI code on top of SimGrid. This
+ module very stable, but if you really don't need it, you can
+ disable it.
+
+ @li <b>enable_mallocators</b> (ON/OFF): disable this when tracking
+ memory issues within SimGrid, or the caching mechanism used
+ internally will fool the debuggers.
+
+ @li <b>enable_jedule</b> (ON/OFF): enable this to get SimDag
+ producing traces that can then be visualized with the Jedule
+ external tool.
+
+ @li <b>enable_lua</b> (ON/OFF): enable this if you want to enjoy the
+ lua bindings of SimGrid. Adds an extra dependency on lua library
+ and developer header files.
+
+
+ @li <b>enable_gtnets</b> (ON/OFF): whether you want to use gtnets.
+ See section @ref pls_simgrid_configuration_gtnets.
+ @li <b>gtnets_path</b> (path): GTNetS installation directory
+ (eg /usr or /opt).
+ @li <b>enable_ns3</b> (ON/OFF): whether you want to use ns3.
+ See section @ref pls_simgrid_configuration_ns3.
+ @li <b>ns3_path</b> (path): NS3 installation directory (eg /usr or /opt).
+ @li <b>enable_latency_bound_tracking</b> (ON/OFF): enable it if you
+ want to be warned when communications are limited by round trip
+ time while doing packet-level simulation.
+ @li <b>enable_documentation</b> (ON/OFF) : whether the documentation should be
+ generated during the compilation. Default is ON.
+
+\subsubsection install_cmake_reset Resetting the compilation configuration
+
+If you need to empty the cache of values saved by cmake (either
+because you added a new library or because something seriously went
+wrong), you can simply delete the file CMakeCache.txt that is created
+at the root of the source tree. You may also want to edit this file
+directly in some circumstances.
+
+\subsubsection install_cmake_outsrc Compiling into a separate directory
+
+By default, the files produced during the compilation are placed in
+the source directory. As the compilation generates a lot of files, it
+is advised to to put them all in a separate directory. It is then
+easier to cleanup, and this allows to compile several configurations
+out of the same source tree. For that, simply enter the directory
+where you want the produced files to land, and invoke cmake (or
+ccmake) with the full path to the SimGrid source as last argument.
+This approach is called "compilation out of source tree".
+
+@verbatim
+mkdir build
+cd build
+cmake [options] ..
+make
+@endverbatim