1. Installation¶
1.1. Quick Start¶
These are simplified instructions for Ubuntu and Fedora. If a step doesn’t work or fit your case, please consult the sections below.
First, get MØD and install the easy dependencies:
git clone --recursive https://github.com/jakobandersen/mod.git
./bootstrap.sh
pip3 install -r requirements.txt
# Ubuntu:
sudo apt install $(bindep -b | tr '\n' ' ')
# Fedora:
sudo dnf install $(bindep -b | tr '\n' ' ')
Then:
Install Boost from source, see Boost and Boost.Python with Python 3. Remember the installation path.
(Optional) Install CPLEX. Remember the installation path.
On Ubuntu: install Graphviz from source:
sudo apt install librsvg2-dev libpango1.0-dev wget http://graphviz.gitlab.io/pub/graphviz/stable/SOURCES/graphviz.tar.gz tar -xf graphviz.tar.gz --one-top-level=graphviz --strip-components=1 cd graphviz ./configure make sudo make install
Finally, compile and install MØD:
mkdir build
cd build
# Without CPLEX:
cmake ../ -DCMAKE_PREFIX_PATH=path/to/boost
# With CPLEX:
cmake ../ -DCMAKE_PREFIX_PATH=path/to/boost -DCPLEX_DIR=path/to/cplex
make
sudo make install
1.2. From a Git Repository¶
After a checkout of the desired version, do:
git submodule update --init --recursive
./bootstrap.sh
This is needed to first fetch certain dependencies and second
to generate build files, extract the API documentation,
and create the file VERSION based on the current commit.
See From a Source Archive on how to then build the package.
1.3. As Dependency of Another CMake Project¶
MØD supports use via add_subdirectory in CMake.
The target mod::libmod is exported,
which can be used with target_link_libraries to link against libMØD.
The version is in the variable mod_VERSION.
Note that running ./bootstrap.sh is still needed if the
source is a repository clone (e.g., a Git submodule).
1.4. From a Source Archive¶
The package is build and installed from source as a CMake project. Generally that means something like:
mkdir build
cd build
cmake ../ <options>
make -j <n>
make install
A source archive can also be created with make dist.
The following is a list of commonly used options for cmake.
Additional options specific for MØD along with their default valule are also
listed.
See also Dependencies for elaboration on some of them.
-DCMAKE_INSTALL_PREFIX=<prefix>, set a non-standard installation directory. Note also that the GNUInstallDirs module is used.-DCMAKE_BUILD_TYPE=<build type>, set a non-standard build type. The default is RelWithDebInfo. An additional build typeOptDebugis available which adds the compilation flags-g -O3.-DCMAKE_PREFIX_PATH=<paths>, set a;-separated list of paths used for finding most dependencies. The paths should generally be the prefixes specified when the dependency was installed. See also https://cmake.org/cmake/help/latest/variable/CMAKE_PREFIX_PATH.html#variable:CMAKE_PREFIX_PATH.-DBUILD_DOC=on, whether to build documentation or not. This is forced tooffwhen used viaadd_subdirectory.-DBUILD_POST_MOD=on, whether to build the post-processor or not.-DBUILD_PY_MOD=on, whether to build the Python bindings or not.-DBUILD_TESTING=off, whether to allow test building or not. This is forced tooffwhen used viaadd_subdirectory. Whenonthe tests can be build withmake testsand run withctest.-DBUILD_TESTING_SANITIZERS=on, whether to compile libraries and tests with sanitizers or not. This is forced tooffwhenBUILD_COVERAGE=on.-DBUILD_EXAMPLES=off, whether to build and allow running of examples as tests or not. This is forced tooffwhen used viaadd_subdirectory. This is forced tooffwhenBUILD_TESTINGisoff.-DBUILD_COVERAGE=off, whether to compile code and run tests with GCov. Whenonthe sanitizers on tests will be disabled. After building the tests, executemake coverage_collectwithout parallel jobs to run tests. Afterwards, executemake coverage_buildto compile the code coverage report.-DENABLE_SYMBOL_HIDING=on, whether symbols internal to the library are hidden or not. Disabling this option may degrade performance, and should only be done while developing extensions to the C++ library.-DENABLE_DEP_SYMBOL_HIDING=on, whether symbols from library dependencies are hidden or not. Disabling this option may make it slower to load the library at runtime.-DENABLE_IPO=on, whether to use link-time optimization or not. Disabling this option may degrade performance, but speed up linking time. As default the link-time optimizer will only use 1 thread. To use more threads, e.g., 7, use the following options for configuration-DCMAKE_MODULE_LINKER_FLAGS="-flto=7" -DCMAKE_SHARED_LINKER_FLAGS="-flto=7", when using GCC as the compiler.-DUSE_NESTED_GRAPH_CANON=on, whether to use the dependency GraphCanon from the Git submodule or not.-DUSE_NESTED_NLOHMANN_JSON=on, whether to use the dependency nlohmann/json from the Git submodule or not.-DWITH_LOLA=on, whether to enable/disable features depending on LoLA.-DWITH_OPENBABEL=on, whether to enable/disable features depending on Open Babel.-DWITH_PNAPI=on, whether to enable/disable features depending on PNAPI.-DWITH_CPLEX=on, whether to enable/disable features depending on CPLEX.-DWITH_CLP=on, whether to enable/disable features depending on CLP.
1.5. Dependencies¶
Python dependencies are listed in requirements.txt (which includes
requirements_nodoc.txt).
Dependencies that can be satisfied via the system package manager are listed in
bindep.txt. Any missing package can be listed using the
Bindep program
(which can be installed via requirements.txt).
The following is a detailed list of all dependencies and the CMake switches related to them.
This documentation requires (
-DBUILD_DOC=on):A supported version of Sphinx.
The Python package
sphinx-autoapi(module name:autoapi).
libMØD:
A C++ compiler with reasonable C++14 support is needed. GCC 6.1 or later should work.
Boost dev >= 1.72 (use
-DBOOST_ROOT=<path>for non-standard locations).GraphCanon >= 0.4. This is fulfilled via a Git submodule (make sure to do
git submodule update --init --recursive), but if another source is needed, set-DUSE_NESTED_GRAPH_CANON=off.nlohmann/json >= 3.7.3. This is fulfilled via a Git submodule (make sure to do
git submodule update --init --recursive), but if another source is needed, set-DUSE_NESTED_NLOHMANN_JSON=off.(optional) LoLA, Low-level petri-net analyser (
-DWITH_LOLA=on).(optional) Open Babel dev, >= 2.3.2 (
-DWITH_OPENBABEL=on).(optional) PNAPI dev, Petri-net API (
-DWITH_PNAPI=on). The build system for PNAPI is unfortunately buggy when either doing out-of-source builds or installing in non-standard locations. A fixed version of the package is included in the MØD distribution.(optional) An ILP solver from the following list. At run-time, use the function
getAvailableILPSolvers()/getAvailableILPSolvers()to see which have been enabled.CPLEX dev (
-DWITH_CPLEX=on, use-DCPLEX_DIR=<path>to specify the installation path). Depending on the CPLEX version it may require a license file to be accessible. See the documentation of CPLEX for this. Newer versions of CPLEX do not have this requirement.CBC dev (
-DWITH_CBC=on) from the COIN-OR package, along with a compatible LP solver:CLP from the COIN-OR package, and included in CBC.
PyMØD (
-DBUILD_PY_MOD=on):Python 3 dev
Boost.Python built with Python 3
(Optional) IPython 3
PostMØD (
-DBUILD_POST_MOD=on):pdflatexavailable in thePATHor inCMAKE_PROGRAM_PATH, with not too old packages (Tex Live 2012 or newer should work).pdf2svgavailable in thePATHor inCMAKE_PROGRAM_PATH.dotandneatofrom Graphviz available in thePATHor inCMAKE_PROGRAM_PATH. They must additionally be able to load SVG files and output as both SVG and PDF files (all via cairo). That is, in the output ofdot -Pthe following edges must exist:cairo_device_svg -> output_svgcairo_device_pdf -> output_pdfrsvg_loadimage_svg -> render_cairo
If you install Graphviz from source, you can check if the status output in the end of
configureincludes the following two lines:pangocairo: Yes rsvg: Yes
1.6. Boost and Boost.Python with Python 3¶
A package with the sources of Boost can be downloaded from http://boost.org.
1.6.1. Basic Installation¶
Boost uses a custom build system which may be difficult to use. A procedure for compiling and installing Boost with Python 3 for Boost.Python is the following.
./bootstrap.sh --with-python=python3(optionally give--prefix=some/pathto specify a non-standard installation path../b2(optionally give-j N(similar to GNU Make) to compile with multiple threads)./b2 install(optionally give--prefix=some/pathto specify a non-standard installation path (if not done earlier).
After bootstrap.sh has been run, the file project-config.jam
has been created, which can be edited to customise installation path and a lot
of other things. All edits should be done before running b2.
1.6.2. Non-standard Python Installation¶
Passing --with-python=python3 to bootstrap.sh should work.
This adds a line similar to “using python : 3.3 ;” to
project-config.jam.
After compilation (running b2) the file stage/lib/libboost_python3.so
should exist. If not, it did not detect Python 3 properly.
If Python is installed in a non-standard location, add the a line similar to
“using python : 3.3 : python3 : /path/to/python/3/installtion/include ;” to
project-config.jam, where the last path is the path to the
include-folder of the Python-installation.