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_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>_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
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_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
.
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