IMP Manual
develop.714915d50b,2024/12/07
|
We use CMake to configure the IMP build when building from source.
There are two different ways to configure with cmake
; one is to run cmake
in a fresh directory passing some options on the command line, and the other is to run ccmake
and use its editor to change options. For both, assume you are in a directory called debug
and the IMP source is in a directory at ../imp
. We are using the default of makefiles for the actual building.
To configure and build as simply as possible do
cmake ../imp make -j8
To make a debug build of IMP with the cgal
and misc
modules disabled and core
compiled in per-cpp mode, and to use Ninja instead of make
as your build command do:
cmake ../imp -DCMAKE_BUILD_TYPE=Debug -G Ninja -DIMP_DISABLED_MODULES=cgal:misc -DIMP_PER_CPP_COMPILATION=core ninja -j8
ccmake ../imp
You can then look through the various options available.CMAKE_BUILD_TYPE
to Debug
c
) and generate (hit g
)make -j8
You can run ccmake
after running cmake
as above if you want, too. Running it never hurts.
You can use Ninja instead if it is available by passing -G Ninja
to the (c)cmake
call. That is highly recommended when it is available.
Various aspects of IMP build behavior can be controlled via variables. These can be set interactively using ccmake
(eg ccmake ../imp
) or by passing them with -D
in a call to cmake
. Key ones include:
CMAKE_BUILD_TYPE
: one of Debug
or Release
.IMP_DISABLED_MODULES
: A colon-separated list of disabled modules.IMP_MAX_CHECKS
: One of NONE
, USAGE
, INTERNAL
to control what check levels will be supported. The default is USAGE
for release builds and INTERNAL
for debug builds (setting this to INTERNAL
will impact performance; NONE
is not recommended as all sanity checks will be skipped).IMP_MAX_LOG
: One of SILENT
, PROGRESS
, TERSE
, VERBOSE
to control what log levels are supported.IMP_PER_CPP_COMPILATION
: A colon-separated list of modules to build one .cpp at a time, or ALL
to do this for all modules.IMP_CUDA
: A colon-separated list of modules to build with CUDA (GPU) support, or ALL
to do this for all modules. This is experimental and is currently in development. See here for more details.IMP_USE_SYSTEM_RMF
: Set to on
to build IMP using an external (system) copy of the RMF library, instead of that bundled with IMP itself.IMP_USE_SYSTEM_IHM
: Set to on
to build IMP using an external (system) copy of the python-ihm library, instead of that bundled with IMP itself.There also are a variety of standard cmake options which control the build. For example:
CMAKE_INCLUDE_PATH
and CMAKE_LIBRARY_PATH
control the paths CMake searches in to locate IMP prerequisite libraries. If your libraries are installed in non-standard locations, you can set these variables to help CMake find them. For example, on a 32-bit RHEL5 system, which has both Boost and HDF5 in non-standard locations, we use -DCMAKE_INCLUDE_PATH="/usr/include/boost141;/usr/include/hdf518/" -DCMAKE_LIBRARY_PATH="/usr/lib/boost141;/usr/lib/hdf518"
CMAKE_INSTALL_PREFIX
should be set if you want to install IMP in a non-standard location.In order to build IMP Python extensions, CMake needs to find the Python header and library files that match the python3
or python
binary. If using a recent version of CMake (3.14 or later) it should have no issues in doing so. However, old versions of CMake might get confused if you have multiple versions of Python installed (for example on a Mac with Homebrew), and find the headers for one version and the binary for another. This can be worked around by explicitly telling CMake where your Python library and headers are by setting the PYTHON_LIBRARY
and PYTHON_INCLUDE_DIR
CMake variables.
For example, on a Mac with Homebrew, where python
is Homebrew's /usr/local/bin/python
, old versions of CMake will often find Apple's Python headers. This can be resolved (if you cannot upgrade CMake to 3.14 or later) by telling CMake where the Homebrew Python headers and library are, by adding to your CMake invocation something like -DPYTHON_LIBRARY=/usr/local/opt/python@3/Frameworks/Python.framework/Versions/Current/lib/libpython3.12.dylib -DPYTHON_INCLUDE_DIR=/usr/local/opt/python@3/Frameworks/Python.framework/Versions/Current/Headers
CMake will attempt to use the newest version of Python available on your machine. If you want to use an older version, one way to do this is to set the Python executable you want to use, e.g. -DPython3_EXECUTABLE=/usr/local/bin/python3
.
For each dependency CMake will first try to find the header and library files for that dependency, reporting success if it finds them. Next, it will often try to build a small C or C++ test program that uses those headers and libraries. If this fails the dependency cannot be used (and CMake will, somewhat confusingly, report that the dependency was first found and then not found). To fix issues like this, check the CMake error log in CMakeFiles/CMakeError.log
to see what failed. In some cases this can be fixed by modifying the flags passed to the C or C++ compiler. For example, recent versions of Protobuf or CGAL fail on some systems because they require C++17 support, and this can be fixed by adding to your CMake invocation -DCMAKE_CXX_FLAGS="-std=c++17"
Note also that CMake searches in the system path (PATH
environment variable) for command line tools such as python
and swig
. Thus, if you have multiple versions of tools (e.g. /usr/bin/swig
and /usr/local/bin/swig
) make sure the PATH
variable is set correctly so that the right tool is found before you run CMake.