I created a command-line portable script-based industrialized agnostic build system useful to quickly build several dependent projects while not having to rely on a particular IDE or a build factory. It's agnostic, because it's not based on a single build engine. I founded the first version using cmake, because my projects are mostly C++, but that'll evolve (to include gradle for example or whatever). That's to say, I'm not centered on CMake, it's merely a tool to a goal, easy portable C++ project building. I had BJam in mind formerly and would have kept it if there had been more documentation.
As a result though, I'm very dependent on CMake to perform the build and unit tests. As of today, I realized that tests are built under the 'all' target and run under the 'test' target.
With CMake 2- (and -here for example- a Unix Makefiles generator):
make all # Build project AND tests
make test # Run tests
With CMake 3+ and any generator:
cmake --build . --target all # Build project AND tests
cmake --build . --target test # Run tests
I'd like to know if someone would know a way to split the 'build project' phase apart from the 'build tests' phase (also because it feels more natural in my build system to join test building and running tests than the other way around).
Important precision: I don't want to bootstrap the project with one vision or another (by flipping BUILD_TESTING). The idea would be to have 3 stages like:
cmake --build . --target <project> # 1. Build project only
cmake --build . --target <build_tests> # 2. Build tests
cmake --build . --target <run_tests> # 3. Run tests
If I choose not to run tests, I could go straight from phase 1 above to installing, but running phase 3 would trigger the previous dependent phases.
Any clue? (If not, I suspect I'll have to ask CMake developers directly...)
Thanks in advance. Regards.
Assuming you choose build_tests target for build test's executables and run_tests target for run them:
Defining targets:
add_custom_target(build_tests)
# 'run_tests' triggers 'ctest'.
add_custom_target(run_tests COMMAND ${CMAKE_CTEST_COMMAND})
# 'run_tests' implies 'build_tests'
add_dependencies(run_tests build_tests)
Creating test's executables, so they won't be built by default but with build_tests target.
# Do not build 'test1' by default
add_executable(test1 EXCLUDE_FROM_ALL ...)
# 'build_tests' implies (among other things) building 'test1'
add_dependencies(build_tests test1)
Related
After
cd build
cmake -B . -DCMAKE_TOOLCHAIN_FILE=~/vcpkg/scripts/buildsystems/vcpkg.cmake -S ..
Looks like
cmake --build .
and
make
do the same here on macOS.
So, when should I use one or the other?
For a simple use there is not much difference, except that cmake --build is more generic and works with any generator. So today you use make, tomorrow ninja or msbuild and CMake handles it with simple cmake --build which you can put in a script or readme.
But since the inception of presets these 2 methods started to really diverge. You can add some things in the build part of your preset which then can be invoked by cmake --build --preset MyPreset while you can't do the same with simple make.
So since you are using CMake as your project tool I'd recommend to start using its interface for the build since that's how it will be meant to use in the future anyway (at least it seems so).
make is not a recognized command in Windows. In times like this, cmake --build . is your friend.
cmake build . also works, sometimes and I don't know the deeper explanations of these phenomena.
cmake -B ...typehere
type - build type
e.g .sln projects for vs studio
make - build your project
cmake - allows you to create a different build types for your project.
I am new to c++ & am referring to the llvm project https://llvm.org/docs/GettingStarted.html. There is a guide saying
If you are space-constrained, you can build only selected tools or only selected targets. The Release build requires considerably less space.
But I am unable to find the exact way to do it.
Currently, I am running the following to build all the tools
mkdir build
cmake ../llvm
make
This would create many tools such as llvm-addr2line, llvm-ar, llvm-dwarfdump etc.
How could I build it such that it only gives me 1 tool, eg llvm-dwarfdump (eg https://llvm.org/docs/CommandGuide/llvm-dwarfdump.html)?
Is there an easy way to know the code that makes up these command.
Thank you
CMake generates a target for every add_library, add_executable, and add_custom_target command. These targets can be built separately by calling make <target> or with the build tool independent CMake abstraction cmake --build <builddir> --target <targetname> --config Release. To find out which targets have been defined by LLVM you need to inspect all CMakeLists.txt and *.cmake files.
I am developing hobby OS which is cross-compiled to other architecture than my development PC and is run in QEMU emulator.
I am trying to introduce unit testing of the source files I develop for my kernel but to let them run on my development machine rather than in QEMU on my target.
In order to cross-compile my sources, I use the toolchain file which uses my custom GCC toolchain. As coming from CMake principle of toolchain file usage, the toolchain file is set up prior to project(...) definition in my root CMakeLists.txt file.
My question is how to build my test executables for my dev machine (x86_64) using the built-in GCC while cross-compiling my kernel binary for target platform... I do not know how to set CMAKE_CXX_COMPILER / CMAKE_C_COMPILER cmake variables specifically for each use case (testing, target build)
To have a look at my particular project, please feel free to navigate here:https://gitlab.com/revolta/revolta
I would like to add test/ to my project root including selected sources from source/... and manage it somehow from my root CMakeLists.txt
Thanks in advance for any concept ideas and help! Cheers Martin
The rule is - there is one compiler per configuration. Do not try to make to use two compilers per configuration. Instead run cmake two times and configure it twice,. separately for x86 testing and separately for releasing to target build.
So write a small script (you have configure.sh anyway) (I usually write a makefile with all PHONY targets) that would run and build the project twice for two configurations:
# ./compile_and_test_your_project.sh
# build for target host
cmake -DCMAKE_TOOLCHAIN_FILE=the_toolchain -S. -B_build/crosscompiled
cmake --build _build/crosscompiled --target the_main_project_target
( cd _build/crosscompiled && ctest )
# build for native host
cmake -DCMAKE_C_FLAGS="-fsanitize=undefined -ggdb3 -O0" -S. -B_build/native
cmake --build _build/native --target only_testing_targets
( cd _build/native && ctest )
Do not set CMAKE_CROSSCOMPILING_EMULATOR inside cmake config. I advise to try to keep cmake configuration platform agnostic as much as you can and pass platform specific parts using arguments to cofiguration cmake. Such way is scalable - you may use a different toolchain and different environment with ease, or try different compiler options. Inside cmake you can see if you are crosscompiling with just if (CMAKE_CROSSCOMPILING). Also see CMAKE_CROSSCOMPILING_EMULATOR.
ps. My makefile from one of my projects that sets different CMAKE_CROSSCOMPILING_EMULATOR depending on make target.
I would like to automate the build of CMake using an MSVC C++ script instead of using CMake-gui to generate the build or CMake terminal or using the CMake integrated on MSVC 2017 by right click on the CMakeLists.txt to build it manually. Assume we have a project (name it: initialize) that includes the CMakeLists.txt and initialize.cpp, so my question is how I can convert these commands into a C++ code, assume build_initialize.cpp:
mkdir build
cd build/
cmake ..
So, the requirement of this tiny C++ code is to
Set the path to this project
Create build folder
Run CMake
At the end if I execute build_initialize.exe, the job is just to build the initialize.cpp using CMake. The goal is to test if the build is success or not as a test case within another project that has several test cases.
You may ask, why I didnot include it to the top CMakelists.txt, and then build it from the beginning using CMake. If I am going to do that, I will get an executable file. As a result, by running the ctest of CMake, the initialize.exe will require a pace of hardware. This is not the goal. My goal is just to build it. If I run build_initialize.exe, just repeat the build using CMake without initialize.exe execution.
Sorry, it could be very simple, but I lack the good experience either in C++ or CMake. Two days have been lost without success.
Thanks to all of you for the comments. The answer has been given by #Fred. To run cmake from C++ script, simply the system() can be used such as: System(cmake -S path_to_src -B path_to_bld).
Useful link: https://faq.cprogramming.com/cgi-bin/smartfaq.cgi?id=1043284392&answer=1044654269
I have a CMake sample project that I would like to build on Jenkins running on Ubuntu 15.10. I have installed:
https://wiki.jenkins-ci.org/display/JENKINS/CMake+Plugin
And created two build steps:
Run CMake to generate makefiles
Run make all from the build dir
It works fine:
[build] $ cmake -G "Unix Makefiles" -D CMAKE_BUILD_TYPE=Debug /var/lib/jenkins/workspace/cmake-test/cmake-gtest/src
-- Configuring done
-- Generating done
-- Build files have been written to: /var/lib/jenkins/workspace/cmake-test/cmake-gtest/build
[build] $ /usr/bin/make
[ 4%] Built target libfoo
[ 9%] Built target libbar
[ 14%] Built target myApp
[ 52%] Built target gmock
[ 90%] Built target gtest
[100%] Built target testfoo
[cmake-test] $ /bin/sh -xe /tmp/hudson1792271459427590561.sh
+ cd cmake-gtest/build
+ make all
[ 4%] Built target libfoo
[ 9%] Built target libbar
[ 14%] Built target myApp
[ 52%] Built target gmock
[ 90%] Built target gtest
[100%] Built target testfoo
Finished: SUCCESS
But is this the recommended approach for using CMake in a CI/Jenkins setup?
Currently, my CMake/Jenkins build will on each push; 1) generate the makefiles, 2) build the project.
I am a bit worried that the first step 1) generate makefiles would eat up build time and it does not really seem optimal to do this step on each push. Especially since I would not expect to change CMakeLists.txt files that often, but when they change newly generated files should, of course, be used.
Is the above approach common practices that I just have to get used to or have I missed something?
Yes, you can do it in one step.
For example, in my Jenkins environment, when building the Ubuntu jobs I use the CMake plugin for the whole compilation, as it allows multiple build tool invocations.
My screenshot at the bottom of this post is of a CMake step in a job (I use Ninja instead of Unix Makefiles, but the effect is the same).
I use two build invocations:
Blank - equivalent to calling ninja or make in a shell,
Install - equivalent to calling DESTDIR=. ninja install.
If I wanted to build additional targets from the makefiles, I could just add extra invocations to this step.
Note that in your screenshot you have a blank invocation in the configuration. This will already be calling make, and as confirmed by your log output, you are in fact compiling your project twice, because of your manual call to make all in the following step.
You can remove your shell step and your project will still build.
Regarding your question on best practices and regenerating CMake, I refer you to this article on Jenkins Best Practices where it states:
To ensure a build can be reproducible, the build must be a clean build, which is built fully from Source Code Control. This practice also implies that all code including third-party jars, build scripts, release notes, etc. must be checked into Source Code Control.
Note that I also check "Clean Build" in my CMake step, so that the entire CMake workspace is wiped out and the project is generated from scratch for every build. This ensures there are no issues caused by stale cache variables, etc.
Screenshot of a CMake step in one of my jobs:
I am not even sure you need this plugin. AFAIR the plugin webpage it is only useful if you want Jenkins to use a specific CMake version, or you want a GUI for which CMake variables you might want to set. I just execute CMake from the command line.
For your second part of the question, If you change CMakeLists.txt, the Makefile will automatically rerun CMake, so strictly speaking it is not necessary to run CMake each time. But on the other side, CMake configuring is quite fast and most likely takes less time than compiling.