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
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>/managedirectory 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
Example directory layout and cmake invocation:
<OPENCMISS_ROOT>/manage/ build/ >> cmake -DTOOLCHAIN=GNU -DMPI=mpich .. build_intel/ >> cmake -DTOOLCHAIN=intel -DMPI=intel ..
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.
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)
The system architecture, e.g.
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:
OC_USE_MULTITHREADINGis enabled, this segment is
/mt. Otherwise, the path element is skipped.
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
Moreover, a path element
no_mpiis used for any component that does not use MPI at all.
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:
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
TOOLCHAINvariable 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>_COMPILERvariables. See the
<manage>/CMakeScripts/OCToolchainCompilers.cmakefile for more background on option one.
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.
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:
MPIvariable 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
NOand let the build system download and compile the specified implementation.
Note that this is only possible for selected implementations and environments that use GNU makefiles, as most MPI implementations are not “cmakeified” yet.
MPI_HOMEvariable 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.