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.

BLA_VENDOR

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.

Caution

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>

BUILD_PRECISION

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

Note

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

BUILD_SHARED_LIBS

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

BUILD_TESTS

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

CMAKE_BUILD_TYPE

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

CMAKE_DEBUG_POSTFIX

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

CMAKE_VERBOSE_MAKEFILE

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

Default value: NO

<COMP>_SHARED

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

<COMP>_VERSION

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.

Caution

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

GITHUB_USE_SSL

Use SSL connection to (default) GitHub repositories

Default value: NO

INT_TYPE

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

MPI_BUILD_TYPE

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

OC_BUILD_ZINC_TESTS

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

Default value: NO

OC_CHECK_ALL

Enable to have maximum compiler checks. Debug builds only.

Default value: YES

OC_COMPONENTS_SYSTEM

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

OC_CONFIG_LOG_LEVELS

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().

Default value: SCREEN WARNING ERROR

OC_CONFIG_LOG_TO_SCREEN

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

OC_CREATE_LOGS

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

OC_DEPENDENCIES_ONLY

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.

Caution

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

OC_MULTITHREADING

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

OC_PYTHON_BINDINGS_USE_VIRTUALENV

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

OC_SYSTEM_<COMP>

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.

Caution

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.

Default value: OPENCMISS_COMPONENTS_SYSTEM_BY_DEFAULT

OC_USE_ARCHITECTURE_PATH

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

Default value: YES

OC_USE_<COMP>

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.

Caution

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.

OC_WARN_ALL

Enable to have maximum compiler warnings. Debug builds only.

Default value: YES

OPENCMISS_INSTALL_ROOT

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.

Caution

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”`

OPENCMISS_SDK_INSTALL_DIR

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.

Note

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.

Caution

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>

OPENCMISS_SDK_INSTALL_DIR_FORCE

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>

PARALLEL_BUILDS

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

Default value: ON