Build system configuration¶
The build system used in Code_TYMPAN is CMake (see CMake). This section does not explain how CMake works but how it is used in Code_TYMPAN. In order to benefit from it, it is recommended you ensure you have basic working knowledge of CMake.
Main entry point¶
The main entry point of the build system is the file CMakeLists.txt
which is to be kept as synthetic as possible ; most build options are
documented and preset in the file tympan-build-options.cmake
.
Note
Do not edit tympan-build-options.cmake
!
In case you need to tune Code_TYMPAN build to your own set-up, you
might be tempted to edit cmake/tympan-build-options.cmake
. This is
not the CMake way to customize a build. In this case you want to
edit the CMake cache by either using ccmake
or
cmake-gui
. See Running CMake regarding this matter.
Platform handling¶
The tympan-platform*.cmake
files are responsible for handling the
platform. The rationale is for tympan-platform.cmake
to detect
the platform, diagnose the unsupported ones and then call
tympan-platform-common.cmake
then
tympan-platform-XXX.cmake
for platform specific settings.
Note
The TYMPAN_COMPONENT_TYPE
option
Code_TYMPAN is split into components, main application and solver
plugins. The components (DataManagerMetier and cie) must be
compiled either as shared library or static ones depending on the
platform. The option is thus declared in build-options
and then set
separately in each platform specific file.
The tympan-platform-common.cmake
file expects each
tympan-platform-XXX.cmake
file to define some hooks :
functions which will be called at later points requiring system
dependent actions. It should check that those hooks are actually
provided as is done for platform_install_hook
[1].
Third party dependencies¶
As explained in Installation Code_TYMPAN has many dependencies, some of which are shipped as a companions source package. Those lightweight dependencies are built as CMake external projects
Some dependencies (CGAL and NMPB2008 notably) require the system to be
able to find some shared libraries / DLL at run time. The
TYMPAN_3RDPARTY_DLL_DIRS
CMake variable is a list of paths which
gets built while configuring dependencies. It can then be used by
installation scripts or test scripts to setup the execution path.
Installation¶
The tympan-utils.cmake
file provides some macros related to
installation which are to be called by components or plugins to
perform their installation. Those macro just end up calling CMake’s
install
command with the right paths and options.
The tympan-install.cmake
configures the overall installation
process, call the platform specific installation hook and add an
uninstall
target.
Tests¶
Most of the tests are currently implemented in C++ using GTest, only the GUI-related ones are implemented using QTest. In both cases the test driver used is CTest which integrates very well with CMake.
The tympan-utils.cmake
notably provides the CMake function
configure_gtest_target
which is called on the test executable to
setup the right dependencies for GTest and register the test with
CTest.
An analogous function is provided for QTest. Contrary to
configure_gtest_target
which configures an existing executable
target, add_qtest_executable
creates itself a new executable
target from the sources: this allows it to launch MOC and add the
generated sources to the executable.
Avoid debug python library on Windows¶
A specific additional step was require to solve the following problem
on Windows when building in Debug: python27_d.lib
is not found
and actually does not exists and is not really needed. This is a known
issue related to Python header pyconfig.h
using the evil MSVC
autolink functionality.
The problem is described and solved by boost::Python : http://www.boost.org/doc/libs/1_53_0/libs/python/doc/building.html#id19
Other lighter solutions found on the Internet are not relevant for the
build system of Code_TYMPAN, especially desactivating the _DEBUG
pre-processor symbol for building pytam
. Indeed pytam
relies
on CGAL which does not support being included both with and without
_DEBUG
(and we definitely need debugging mode of CGAL).
The solution is to insert an ad-hoc patch step (implemented by the
cython_patch.py
script) in between the generation of pytam.cxx
from pytam.pyx
by Cython and the actual compilation of the file.
This patch step replaces the direct inclusion of pyconfig.h
and
Python.h
by inclusion of custom wrappers (tympan_wrap_*.h
)
which are adapted from those used by boost to solve the very same
problem (boost/python/detail/wrap_python.hpp
).