The default configuration file is located at <manage>/Config/OpenCMISSDefaultConfig.cmake In order to change any of the subsequently listed variables, specify your values in the local config file.


Define a BLAS library vendor. This variable is consumed by the FindBLAS/FindLAPACK modules. Not specifying anything will perform a generic search. If you have the Intel MKL library, use e.g. Intel10_64lp.


If you change the BLAS implementation after a previous build has finished, the binaries for the old BLAS version will be overwritten by the ones using the specified BLAS implementation. This could be avoided if the BLAS implementation type was somehow reflected in the architecture path, however, having installations for the same toolchain and compiler but different BLAS libraries is not expected to be necessary. This might change in future versions.

This is a native CMake variable. See also the official BLA_VENDOR documentation

Default value: <empty>


The flags sdcz are available to be set in the :cmake:BUILD_PRECISIONS variable. It is initialized as cache variable wherever suitable.


Currently LAPACK/BLAS is always built using dz minimum, as suitesparse has test code that only compiles against both versions (very integrated code). SCALAPACK is always built with s minimum.

Valid choices are s,d,c,z and any combinations:
s:Single / float precision
d:Double precision
c:Complex / float precision
z:Complex / double precision

Default value: sd


Enable this flag to build all the components libraries as shared object files (*.so / *.dll). The default behaviour is to build all the dependencies’ libraries as static and only the main components Iron and Zinc as shared libraries.

See also: <COMP>_SHARED_

This is a native CMake variable. See also the official BUILD_SHARED_LIBS documentation

Default value: NO


Most OpenCMISS components come with their own test cases and suites. This flag enables all component tests to be build along with the components.

This does not mean they’re run (which you should do, see Available build targets)

Default value: ON


For different build types, use this variable. Possible values are (in general)

RELEASE:Optimised build
DEBUG:Build including debug information
MINSIZEREL:Optimised build for minimal library/binary size
RELWITHDEBINFO:Optimised build with debug information

This is a native CMake variable. See also the official CMAKE_BUILD_TYPE documentation

Default value: RELEASE


Specifies a postfix for all libraries when build in CMAKE_BUILD_TYPE=DEBUG

This is a native CMake variable. See also the official CMAKE_DEBUG_POSTFIX documentation

Default value: d


This is a native CMake variable. See also the official CMAKE_VERBOSE_MAKEFILE documentation

Default value: NO


This flag determines if the specified component should be build as shared library rather than a static library. The default is NO for all components except Iron and Zinc.

Default value: NO


These variables are the essential part of the build systems package version management.

For each OpenCMISS component, this variable contains the current required (minimum) version for that component - OpenCMISS uses Git in conjunction with version-number named branches to maintain consistency and interoperability throughout all components. The Git repository default branches are constructed by a “v” prefix to the version: v${<COMP>_VERSION}

Those quantities are not intended to be changed by api-users, but might be subject to changes for development tests. Assuming the existence of the respective branches on GitHub, all that needs to be done to change a package version is to set the version number accordingly. The setup will then checkout the specified version and attempt to build and link with it.


Having a consistent set of interoperable packages (especially dependencies) is a nontrivial task considering the amount of components, so be aware that hasty changes will most likely break the build!

Moreover, those variables are also defined for all MPI implementations that can be build by the OpenCMISS build environment.

See also: <COMP>_BRANCH


Use SSL connection to (default) GitHub repositories

Default value: NO


Some packages allow int64 or longint as integer types - this has not been tested for anything but int32 Used only by PASTIX yet

Default value: int32


For different MPI build types, use this variable. Possible values are (in general)

RELEASE:Optimised build
DEBUG:Build including debug information
MINSIZEREL:Optimised build for minimal library/binary size
RELWITHDEBINFO:Optimised build with debug information

Default value: RELEASE


Allow users to build the tests for Zinc in isolation to other testing.

Default value: NO


Enable to have maximum compiler checks. Debug builds only.

Default value: YES


Global setting to control use of system components. Possible values:

DEFAULT:Holds only for the components specified in OPENCMISS_COMPONENTS_SYSTEM_BY_DEFAULT (Config/Variables.cmake)
NONE:The OpenCMISS build system exclusively builds components from its own repositories
ALL:Enable search for any component on the system

Default value: DEFAULT


This variable controls the messages generated and written to the configure log files during the CMake configuration phase. It is intended for developers and anyone trying to debug the CMake scripts. Possible values are:

SCREEN:Also print the log text to the console.
WARNING:Equivalent to issuing message(WARNING ...). However, the warning text will also be put into the log file.
ERROR:Equivalent to issuing message(FATAL_ERROR ...). However, the error text will also be put into the log file.
DEBUG:Any output not intended for production use, but thought useful for debugging purposes.
VERBOSE:Verbose output, thought of as the maximum verbosity level.

The build log files are put into the <CMAKE_CURRENT_BINARY_DIR>/support folder into a file with the pattern configure_builds_YYYY-MM-DD_hh-mm.log. The function to write log entries is called log().



Have all non SCREEN-level logs are also printed on the console (helps debugging). See also OC_CONFIG_LOG_LEVELS. .. default:: NO


Have the build system wrap the builds of component into log files. Selecting NO will directly print the build process to the standard output.

Default value: YES


If you want to compile the dependencies for iron/zinc only, enable this setting. This flag is useful for setting up sdk installations or continuous integration builds.


You can also disable building Iron or Zinc using the component variables, e.g. OC_USE_IRON=NO. However, this is considered a special top-level flag, which also causes any components that are exclusively required by e.g. Iron will not be build.

See also OC_USE_<COMP>_

Default value: NO


The build environment uses this to control if “local” multithreading should be enabled/used. Thus far only OpenMP is implemented in the build system (and not for every component), so this controls the WITH_OPENMP flag being passed to any dependencies that can make use of it. If used, the architecture path will also contain an extra segment “mt” between MPI and toolchain parts.

Default value: NO


This option allows to use the Python virtual environments to conveniently switch between the different bindings created for different compiler/mpi/build configurations.

The build system will issue an error if this option is turned on and the virtualenv executable can not be located.

Default value: YES if prerequisites are found, NO else


Many libraries are also available via the default operating system package managers or downloadable as precompiled binaries. This flag determines if the respective component may be searched for on the local machine, i.e. the local environment.

As there are frequent incompatibilities with pre-installed packages due to mismatching versions, these flags can be set to favor own component builds over consumption of local packages.

The search scripts for local packages (CMake: find_package command and Find<COMP>.cmake scripts) are partially unreliable; CMake is improving them continuously and we also try to keep our own written ones up-to-date and working on many platforms. This is another reason why the default policy is to rather build our own packages than tediously looking for binaries that might not even have the right version and/or components.


Applies to setting in OpenCMISSLocalConfig only: If you decide to enable one of those variables at some stage and later want to disable it, just commenting out like #set(OC_SYSTEM_MUMPS YES) will not set its value to NO, as it is registered as an CMake option. You need to explicitly set the value to NO to have the desired effect.

See also: OC_COMPONENTS_SYSTEM and the OPENCMISS_COMPONENTS_SYSTEM_BY_DEFAULT variable in <manage>/Config/Variables.cmake.



Controls use of architecture paths. If you will only ever build everything with one toolchain/mpi config, set this to NO.

Default value: YES


For every OpenCMISS component, this flag determines if the respective component is to be used by the build environment. This means it’s searched for at configuration stage and build if not found.

The list of possible components can be found in the OPENCMISS_COMPONENTS variable in <manage>/Config/Variables.cmake.


There is no advanced logic implemented to check if a custom selection of components breaks the overall build - e.g. if you disable OC_USE_LIBXML2 and there is no LibXML2 installed on your system, other components requiring LIBXML2 will not build correctly.

See also OC_SYSTEM_<COMP>_ and the OPENCMISS_COMPONENTS_DISABLED_BY_DEFAULT variable in <manage>/Config/Variables.cmake.


Enable to have maximum compiler warnings. Debug builds only.

Default value: YES


The root directory where all libraries, include files and cmake config files for ALL architectures will be installed. For details on the architecture path used within OPENCMISS_INSTALL_ROOT, see Architecture paths.


Developers only Take care whether you specify this variable in the local configuration or the developer configuration file. With local configuration, you can specify different install roots for each architecture (if desired). Placing it in the developer config takes precedence over all local configurations and hence determines a global installation root for all build configurations.

Default value: `”<OPENCMISS_ROOT>/install”`


If you have a remote installation of opencmiss components, (e.g. you are using OpenCMISS in a shared network environment) specify the installation directory here. This will have the build environment search for opencmiss components at that location.


There are alternate ways to specify the remote install directory.
  • Set OPENCMISS_SDK_INSTALL_DIR in your system environment to have the build system use that automatically.
  • Specify -DOPENCMISS_SDK_INSTALL_DIR at the main build, it will cache the variable and insert it into this file automatically.


You do NOT have to specify the full architecture-path dependend installation directory. OpenCMISS will try to find a matching subpath for your local compiler and mpi settings and issue a warning if no matching installation can be found.

Default value: <empty>


If using OPENCMISS_SDK_INSTALL_DIR fails and you are sure that the remote installation is compatible, you can also directly specify the remote directory containing the “context.cmake” file in this variable.

For example, this could be useful if you wanted to compile an example using a different toolchain than that used to compile the OpenCMISS libraries. This is intended for developers only and has not been thoroughly tested.

Default value: <empty>


Enable this flag to have the build system automatically use multithreaded builds

Default value: ON