I am trying to build an [open-source project|https://github.com/openMVG/openMVG] with OpenMP support. However, I am doing so on a mac, and therefore I don't have native OpenMP support.
There are numerous OpenMP Clang projects out there (http://openmp.llvm.org/ and https://clang-omp.github.io/).
My question is, how do I configure my system so that the open source project requires little to no modification to compile with OpenMP support?
Normally cmake would auto discover what compiler to use, then check it against the requirements set by the project - e.g. check for openmp support - and then write a Makefile. You can tell it what compiler to use by either specifying the variables CC and CXX before the call to cmake or by passing the flags -DCMAKE_C_COMPILER and -DCMAKE_CXX_COMPILER. The project requires no changes to make this work.
Normally you could use homebrew to get an openmp-supporting compiler: clang-omp or gcc (real, not apple's). Then you would configure the project specifying your compilers. In this case clang-omp won't work because the build scripts assume you will be linking against libgomp, so go with gcc-5:
git clone openMVG
cd openMVG
git submodule update --init
mkdir build_dir && cd build_dir
CC=gcc-5 CXX=g++-5 cmake ../src
Related
The good news, I was able to compile and install Clang and lld from branch llvmorg-12.0.1 under Windows / Cygwin.
It compiles my code fine but linker says:
lld: error: unknown argument: --dll-search-prefix=cyg
I am wondering because of I thought lld takes the same cli parameters as ld.
I am working on a project which includes gtest and uses the cmake framework. The files for testing are linked as library and later again the tests and finally again gtest.
The code is linking and working when using ggc 11.2.0
--dll-search-prefix is a win32-specific option of ld which is not (yet) implemented in lld.
I have just acquired an arbitrary CMake project from the internet and I am not sure how to compile it. What commands do I need to run to build it from the command line?
Basic steps
If you're on a Unix-y operating system, like Linux or macOS, then you would run:
$ cmake -DCMAKE_BUILD_TYPE=Release -S /path/to/source-dir -B /path/to/build-dir
$ cmake --build /path/to/build-dir
Here, /path/to/source-dir is the directory containing the root-level CMakeLists.txt, this is most commonly the root of a source control repository. Meanwhile, /path/to/build-dir is a distinct directory (that does not need to exist yet) that CMake will use to store the generated build system and its outputs. This is called an out-of-tree build. You should never attempt an in-tree build with CMake because of the possibility of name clashes and difficulty involved with cleaning up the generated files.
When building with a single-config generator (like Make, which is the default on Unix), you specify the build type by setting the CMAKE_BUILD_TYPE variable in the first command, known as the configure step. You must always set this variable when working with a single-config generator. The built-in configs are Debug, Release, RelWithDebInfo, and MinSizeRel. See this answer for more detail on this.
After the configure step, you may build the project by either calling the underlying build tool (in this case, make) or by calling CMake's generic build launcher command (cmake --build), as I do here.
If you're on Windows, then the default generator is Visual Studio, which is a multi-config generator. This means the build type is chosen during the build step rather than the configure step, and the commands must be adjusted accordingly:
$ cmake -S /path/to/source-dir -B /path/to/build-dir
$ cmake --build /path/to/build-dir --config Release
These steps assume that the CMake build you are looking at is well behaved. If a project fails to build with the above steps and you have all of its dependencies installed to system locations (and they are well behaved), then you should open an issue with the upstream project. The most common source of bad behavior in mature CMake builds is dependency handling. Too often you will have to read the build or its documentation to determine which variables need to be set (via -D, like we did with CMAKE_BUILD_TYPE above) for the project to find its dependencies.
Advanced topics
Setting options and cache variables
Some projects offer options to enable/disable tests, components, features, etc. These are typically done by writing entries to the CMake cache during the configure step. For example, a common way to disable building tests is to set BUILD_TESTING to NO at the command line:
$ cmake -S /path/to/source-dir -B /path/to/binary-dir [...] -DBUILD_TESTING=NO
This particular variable is a convention, but is not guaranteed to be honored. Check the project's documentation to see which options are available.
Selecting a generator and toolchain
When using the Visual Studio generators specifically, you can tell CMake which platform you wish to target and which version of the compiler you would like to use. The full form of the CMake configure command for this is:
$ cmake -G "Visual Studio 16 2019" -A <ARCH> -T<TOOLSET> [...]
Valid values of <ARCH> include Win32, x64, ARM, and ARM64. If <TOOLSET> is not specified, then the 32-bit MSVC compiler will be used. Typically, you will want this to be host=x64 to ensure that 64-bit MSVC is used, which can allocate more memory for large linking steps. You can also set <TOOLSET> to ClangCL to use the Visual Studio provided ClangCL tools.
On all generators, CMake sniffs the environment for which compiler to use. It checks the CC and CXX environment variables for the C and C++ compilers, respectively. If those are empty, it will look for cc and c++ executables in the PATH. You can manually override the compilers by setting the CMAKE_C_COMPILER and CMAKE_CXX_COMPILER CMake cache (not environment) variables at the CMake command line (using -D again).
Installing & using dependencies
Once a CMake project has been built, you may install it either systemwide or (preferably) to a local prefix by running:
$ cmake --install /path/to/build-dir --prefix /path/to/install-dir [--config Release]
Where --config is only required if a multi-config generator was used. Once installed to a local prefix, a project that depends on it may be configured by setting CMAKE_PREFIX_PATH to /path/to/install-dir.
I am try to build lld from LLVM version 11 (I can't use any later or master version of LLVM for the time-being) and am currently configuring with cmake ~/Downloads/lld-11.0.0.src/ -DCMAKE_INSTALL_PREFIX=$HOME/bin/llvm -DCMAKE_PREFIX_PATH=$HOME/bin/llvm -DCMAKE_BUILD_TYPE=Release -G Ninja but ninja install then fails with 20 errors that I think are all standard library related (such as "unknown type name 'constexpr'" and "no template named 'underlying_type_t' in namespace 'std'; did you mean 'underlying_type'?").
The compiler cmake is using by default is Apple Clang 12 which came with my system (or was installed automatically). What other flags should I pass to cmake to get this working? Or do I need to use a different compiler? LLVM 11 configures and builds fine with the same cmake flags.
For anyone else experiencing similar issues: Building LLVM, lld and clang from the monorepo all in one go worked. I had to add -DLLVM_ENABLE_PROJECTS="clang;lld" to the cmake command.
I'm trying to create a CMake project that integrates 2 sub-projects, specifically botan and rnpgp. The build system of rnpgp is CMake-based, botan uses a Python configure script to generate a Makefile.
The problem is that during the CMake run rnpgp checks for features in botan, so it requires a compiled botan library. But, botan doesn't get built until I actually call make, which I can't do because rnpgp fails to configure because botan isn't built yet.
What's the right way to specify such a dependency in CMake?
You could use CMake's execute_process() to run the botan Python script and run make during the CMake configure stage. This way, the botan library will be built and available to reference when running the mpgp CMake:
# Run the Python script to configure the botan Makefile.
execute_process(COMMAND
python ${CMAKE_SOURCE_DIR}/botan/configure.py
WORKING_DIRECTORY "${CMAKE_SOURCE_DIR}"
)
# Run 'make' from the botan directory where the 'Makefile' was created.
execute_process(COMMAND
make
WORKING_DIRECTORY "${CMAKE_SOURCE_DIR}/botan/build"
)
This is a rough example of what it could look like. You may have to modify the paths a bit to match where you have botan on your system, and where botan generates its build artifacts (i.e. location of the Makefile).
I'm currently changing the build system on my project, from gnu makefiles to cmake (that generate makefiles).
My project generates several libraries (.lib), and several executables (.exe).
Currently i generate the makefiles using the following command :
cmake -G "Unix Makefiles" .. -DCMAKE_BUILD_TYPE=Debug
The generated makefiles contain an all target, as well as a target for every executable (compiled as such with the add_executable cmake directive), so i can compile a subset of the project (which saves a lot of time) : make executable_1; make executable_2 and so on.
However, there is no target for the libraries (compiled as such with the add_library cmake directive) so i cannot do make library_1 for example. I want to do this because it would save a lot of time.
I tried to add a dummy executable in the library's cmake, and link the library to this executable (which only contains a main without actually using library_1's code).
add_library(library_1 test.cpp)
add_executable(dummy_exe dummy_main.cpp)
target_link_library(dummy_exe library_1)
It does add a target for dummy_exe but does not build the library because it does not actually need to link any of the library_1's code.
This was a workaround attempt anyway, and i'd rather just call make library_1 after all. Is there any way to add a makefile target for a library using cmake ?
As answered by w-m and Fred, CMAKE indeed create a target for libraries in the Makefile.
I was trying to build the library with the cmake subproject name of the library instead of the library name.
make help was indeed of big help to find this issue, as it lists everything that can be built.