This is problematic when you use add_subdirectory() to compile some external dependencies which do not compile without warnings. The warnings are used to compile everything with warnings enabled. There compilation failed due to warnings, which was annoying. I occasionally forgot to do that, implemented a feature, pushed it to CI.
#CMAKE CLEAN UPDATE#
You have to remember to manually update CMAKE_CXX_FLAGS on CI and on every locale development machine. While this approach definitely works, it has a couple of problems: That way the compiler will always have the warning flags enabled. Stay tuned for part 2, where we’ll introduce an external dependency and get rid of the hard-coded fact.Cmake -DCMAKE_CXX_FLAGS = "-Werror -Wall -Wextra …" Build files have been written to: /path/to/build/default If we change just the main.cpp, we just have to rebuild and relink the cpp_demo: $ ninjaīut if we change ChuckNorris.cpp, everything except needs to be rebuilt: Building CXX object CMakeFiles/chucknorris.dir/src/Īnd if we change the CMakeLists.txt file, Ninja will re-run CMake for us: $ ninja Note that CMake and Ninja cooperate so that you only rebuild what’s need to be rebuilt.
Linking CXX static library libchucknorris.a Building CXX object CMakeFiles/cpp_demo.dir/src/ Building CXX object CMakeFiles/chucknorris.dir/src/ CMake uses the current working directory as the build folder, and you must specify the path to the folder containing the CMakeLists.txt file as the last argument on the command line: $ mkdir -p build/defaultĪnd now we use ninja to build build and run our executable from the build folder: $ cd build/default So let’s create a folder named build/default and call CMake, asking it to use the Ninja generator. If we want to, we can have several build folders, all using the same sources, but using different compilers or flags without risking mixing incompatible binaries.gitignore file, instead of a bunch of files We’ll only have to put the build folder into our.It’s cleaner to have them put inside a dedicated build folder instead: o files and the cpp_demo executable) directly in the current working directory. In our first attempt, we generated all the binaries ( libchucknorris.a, the. I’ve already explain why I prefer using CMake with Ninja in an other blog post. There are plenty of generators available, but for now we’ll only talk about Ninja. Instead it generates files that will be used by an other tool.
#CMAKE CLEAN HOW TO#
Now that we have described what we want to build and how, we still need to perform the build itself.ĬMake does not know how to actually perform the build. This will allow us to use modern C++ features (available in C++ 11 or later) such as the auto keyword or raw string literals later on. You can read more about this in the CMake documentation.Īlso note how we set the CMAKE_CXX_STANDARD variable. If the headers were used only to compile the library, we would have used the PRIVATE keyword, and if they were used only by consumers of the library, we would have used the INTERFACE keyword instead. (We used the -I include/ flag both for building libchucknorris.o and ) The target_include_directories informs CMake that there are header files in the include directories that should be used both when builing the library itself, but also by consumers of the library. The add_library and add_executable commands describe the two targets (named chucknorris and cpp_demo) and the sources used to build them, and the target_link_libraries command tells CMake that cpp_demo depends on chucknorris.
Cmake_minimum_required( VERSION 3.10) set( CMAKE_CXX_STANDARD 11) project( ChuckNorris) add_library( chucknorris include/ChuckNorris.hpp src/ChuckNorris.cpp ) target_include_directories(Ĭhucknorris PUBLIC "include" ) add_executable( cpp_demo src/main.cpp ) target_link_libraries( cpp_demo chucknorris)
0 kommentar(er)
