CppCon 2017: Mathieu Ropert “Using Modern CMake Patterns to Enforce a Good Modular Design”

What people said

Recommends legalize · 2017-10 · Stack Overflow · on “how include external library in c++ with cmake”

I'd recommend `target_include_directories` instead of `include_directories`. See this presentation [this video] for best practices of modular CMake build.

Recommends Rich von Lehe · 2018-10 · Stack Overflow · on “CMake top-level configuring sub-modules”

@Tsyvarev - I agree that separate projects for dependencies (creating a package then find_package() is the ultimate for decoupling, but I've not heard that is a requirement to being "modern". I watched Mathieu Ropert's CppCon talk recently and it seems perfectly legit to be using add_subdirectory and conforming to modern CMake ideals. His emphasis is that modern CMake is all about modularity. You can achieve modularity whether your target is defined within the scope of a project or external to a project. [this video]

Recommends Pesho_T · 2019-11 · Stack Overflow · on “Git and CMake project structure, external libraries and packages”

I'd go as far as saying that bundling dependencies with your project is bad practice full stop, nomatter what build system/generator you use. And as arrowd already mentioned [LINK] you will then have to resolve your dependencies' dependencies which is a can of worms you don't want to open. CMake in particular has pretty powerful dependency management system, via the find_package [LINK] command, as well as a powerful interface to pkg-config [LINK] via FindPkgConfig [LINK] and pkg_check_modules [LINK] During configuration, if a required dependency is not found , CMake will print a message which makes it clear which library is missing, and it is then up to the user to install this and resolve i

Recommends Evg · 2019-11 · Stack Overflow · on “How to install the C++20 range library from github”

@M.Mac, I really can't recommend a single good self-contained tutorial. Take a look at these talks: Introduction to CMake [LINK] , Effective CMake [LINK] and Using Modern CMake Patterns... [this video] .

Recommends adam.hendry · 2021-11 · Stack Overflow · on “Why do we need cmake?”

The short answer is that you don't, but it would probably be difficult to build the project without it. CMake does not build code, but is instead a build file generator . It was developed by KitWare (during the ITK project around 2000) to make building code across multiple platforms "simpler". It's not an easy language to use (which Kitware openly admits), but it unifies several things that Windows, Mac, and Linux do differently when building code. On Linux, autoconf is typically used to make build files, which are then compiled by gcc/g++ (and/or clang) On Windows, you would typically use the Visual Studio IDE and create what they call a "Solution" that is then compiled by msvc (the Microso

Recommends TallChuck · 2022-05 · Stack Overflow · on “How do you set compile flags in CMake?”

As pointed out by LHLaurini in the comments, you should use quotes around the flags when assigning them to variables. If you don't, CMake will turn them into a semicolon-delimited list and mess up the commands. Here's an example of how to do it correctly: set(CXXFLAGS "-fopenmp -Wall -std=c++17 -MMD -I${slate_dir}/include -DSLATE_NO_CUDA") set(CMAKE_CXX_FLAGS "${CXXFLAGS}") More importantly, however, writing CMake files involves a very different paradigm from writing Makefiles. Modern best practices would recommend setting flags and libraries as properties of specific targets. Here's a presentation [this video] I would recommend to learn more about this paradigm. If you apply these design princip

Cites legalize · 2017-10 · Stack Overflow · on “Linking against built static libraries rather than using add_subdirectory?”

Linking is all about resolving symbols so that the final target (standalone executable or shared object) has everything it needs to be launched. Things are simple when you depend only on a single library or upon a collection of libraries that in turn depend on nothing else. This is less likely to be the case for any program of moderate or larger size. The underlying issue is how to deal with transitive dependencies, e.g. the dependencies of the things directly used by your program. CMake understands all of this and is designed to make it simple for you to consume libraries without understanding the entire dependency graph. If you look at the documentation for target_link_libraries [LINK] , y

Cites dani · 2018-02 · Stack Overflow · on “Can there be an impact on build time when include/link libraries PUBLIC or PRIVATE?”

As explained here [this video] , in modern cmake you should keep include/link targets private. Your CMakeList.txt should somewhat look like this: add_executable(myexe main.cpp) target_include_directories(myexe PRIVATE ${mylib_include_dir}) target_link_libraries(myexe PRIVATE mylib) Can it make a difference, regarding build time, if I use PRIVATE or PUBLIC ?

Cites kola · 2018-04 · Stack Overflow · on “Issue on using {fmt} as a dependency with CMake”

@Tsyvarev , no there is no path ${project_root}/dev/fmt which would have resolved the issue. Obviously I can add `include_directories(${CMAKE_CURRENT_SOURCE_DIR}/fmt)` to root CMakeLists.txt, but as it comes from presentation by Mathieu Ropert: video [this video] (slides page 44) `include_directories()` is considered harmful. And on the same slide it i stated: _Don’t use TARGET_INCLUDE_DIRECTORIES() with a path outside your module_.

Cites BenW · 2019-03 · Stack Overflow · on “Modern CMake, using target_link_library for external binary library”

I'm trying to use an external binary library using modern CMake. I've been reading a number of examples, and trying to understand the CMake documentation, but I'm having trouble applying it to my specific case. Here is the "modern" CMake talk: [this video] He describes a modular approach to CMake that I'd like to use. My external module looks like this: /usr/local/... include ├── corvusoft │ └── restbed │ ├── byte.hpp │ ├── common.hpp │ ├── context_placeholder_base.hpp │ ├── context_placeholder.hpp │ ├── context_value.hpp │ ├── http.hpp │ ├── logger.hpp │ ├── request.hpp │ ├── resource.hpp │ ├── response.hpp │ ├── rule.hpp │ ├── service.hpp │ ├── session.hpp │ ├── session_manager.hpp │ ├── settin