Building for multiple architectures/configurations¶

If you want to compile OpenCMISS using different compilers, MPI implementations etc., the build environment is aware of most common “architecture” choices and automatically places builds in appropriate architecture paths. Most importantly:

All architecture choices except toolchain and MPI configuration can be made inside the local config files (and developer config files). Toolchain and MPI setup are explained below. See also the main CMakeLists.txt file.

You need a different base binary directory for each intended toolchain/mpi combination! The build instructions above are laid out by default for only one (=the default) toolchain and mpi choice.

The name and place of the different binary directories are up to you, however, we recommend to put them inside the <OPENCMISS_ROOT>/manage directory to get simple cmake ..-style invocations without lengthy relative source directory paths.

If you decide to put them somewhere else (e.g. <OPENCMISS_ROOT>/build/my_toolchain_mpi_combo), you will need to invoke cmake at that location and pass an absolute or relative path to <OPENCMISS_ROOT>/manage as argument.

Example directory layout and cmake invocation:

<OPENCMISS_ROOT>/manage/
   build/
   >> cmake -DTOOLCHAIN=GNU -DMPI=mpich ..
   build_intel/
   >> cmake -DTOOLCHAIN=intel -DMPI=intel ..

Caution

As the sources for one OpenCMISS installation are the same for each different architecture build, you cannot have two different source versions (e.g. branches) for any component for two or more different architectures. For example, you cannot have the current release version of IRON within a build using Intel MPI and the devel version of IRON with OpenMPI. To solve this, you need two different OpenCMISS root installations.

Architecture paths¶

In order to allow simultaneous installation of builds for various configuration and choices, OpenCMISS uses an architecture path to store produced files, libraries and headers into separate directories.

The architecture path is composed of the following elements (in that order)

architecture:
The system architecture, e.g. x86_64_linux

toolchain:
The toolchain info for the build. This path is composed following the pattern /<mnemonic>-C<c_version>-<mnemonic>-F<fortran_version>, where mnemonic stands for one of the items below, c_version the version of the C compiler and fortran_version the version of the Fortran compiler.

All the short mnemonics are:

absoft: The Absoft Fortran compiler

borland: The Borland compilers

ccur: The Concurrent Fortran compiler

clang: The CLang toolchain (commonly Mac OS)

cygwin: The CygWin toolchain for Windows environments

gnu: The GNU toolchain

g95: The G95 Fortran compiler

intel: The Intel toolchain

mingw: The MinGW toolchain for Windows environments

msvc: MS Visual Studio compilers

pgi: The Portland Group compilers

watcom: The Watcom toolchain

unknown: Unknown compiler

multithreading:
If OC_USE_MULTITHREADING is enabled, this segment is /mt. Otherwise, the path element is skipped.

mpi:
Denotes the used MPI implementation along with the mpi build type. The path element is composed as /<mnemonic>_<mpi-build-type>, where mnemonic/mpi-build-type contains the lower-case value of the MPI/MPI_BUILD_TYPE variable, respectively.

Moreover, a path element no_mpi is used for any component that does not use MPI at all.

buildtype:
Path element for the current overall build type determined by CMAKE_BUILD_TYPE. This is for single-configuration platforms only - multiconfiguration environments like Visual Studio have their own way of dealing with build types.

For example, a typical architecture path looks like:

x86_64_linux/gnu-C4.6-gnu-F4.6/openmpi_release/release

Toolchain/compiler choice¶

With CMake and a “normal” toolchain setup, one shouldn’t have to change any compilers as CMake finds the default ones and uses them. However, if for some reason your default compiler setup is messed up or you need a specific compiler, there are two ways to change them:

Define the TOOLCHAIN variable on the command line via -DTOOLCHAIN=[GNU|Intel|IBM] or specify the corresponding quantities in your CMake GUI application. The values listed are currently supported and the build system has some included logic to locate and find the correct toolchain compilers.

Specify the desired compilers for any language explicitly using the CMAKE_<lang>_COMPILER variables. See the <manage>/CMakeScripts/OCToolchainCompilers.cmake file for more background on option one.

MPI¶

MPI is a crucial dependency to OpenCMISS and is required by many components, especially Iron. By default, CMake looks and detects the system’s default MPI (if present) and configures the build system to use that.

Note

If you only want to build Zinc, specify MPI=none in order to deactivate the use of MPI. See also Building only Iron or Zinc

If you want a specific MPI version, there are several ways to achieve that:

Use the MPI variable and set it to one of the values [mpich, mpich2, openmpi, intel, mvapich2, msmpi], e.g. cmake -DMPI=mpich. The build system is aware of those implementations and tries to find according compiler wrappers at pre-guessed locations.
If you want the build environment to build the specified MPI for you, set SYSTEM_MPI to NO and let the build system download and compile the specified implementation.

Note

Note that this is only possible for selected implementations and environments that use GNU makefiles, as most MPI implementations are not “cmakeified” yet.
Set the MPI_HOME variable to the root folder of your MPI installation. CMake will then exclusively look there and try to figure the rest by itself.
Specify the compiler wrappers directly by providing MPI_<LANG>_COMPILER, which should ideally be an absolute path or at least the binary name. Possible values for <LANG> are C,CXX and Fortran (case sensitive!).

At a later stage, the option MPI=none is planned to build a sequential version of opencmiss.