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

CppCon.org
-
Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/CppCon/CppCon2017
-
CMake is the build system chosen by most open-source C++ projects. While it is fully capable of helping you enforce a good modular design, those features are usually not well known or understood.
In this talk I will present modern CMake practices that will simplify your project build and help you design better C++ components with clear dependencies and build interfaces (the sum of compile flags required to use a given library).
We will first do a quick recap of the theory behind modular design, most of it coming from John Lakos' work on Large Scale C++ Software Development. Then we will see a few of the legacy CMake patterns that can be found in a lot of open source projects and explain their shortcomings. We will learn how to create a clean C++ library using modern CMake practices and depend on it in others modules. Finally, we will explore the options available to export the build interfaces for use by external projects. In this last part a few external tools will be discussed such as pkg-config and Conan.
-
Mathieu Ropert: Senior Developer, Murex
Mathieu is a Senior Developer at Murex where he works as a C++ expert and animates internal workshops & events. A long term open-source enthusiast, he tries to make C++ more portable across platforms. He is also co-host of the Paris C++ Meetup.
-
Videos Filmed & Edited by Bash Films: www.BashFilms.com *-----*
Register Now For CppCon 2022: cppcon.org/registration/
*-----*

[@jaredmulconry]

We need more CMake talks like this. As a relatively new user, understanding best practices is incredibly difficult because the examples I find are full of very weird patterns and it's hard to dig through the abstractions in a large CMake project to find the smart things that are going on (or not-so-smart)

[@DavePoo]

Agreed, i've cleaned up the cmake files in my project since watching this. I could see when i wrote them that something was wrong as i was having to include files and repeat flags and include directives in different projects. It seemed bad, but i didn't know any better, and the cmake documenation is very reference based, so really doesn't try to lead you down the correct path. This talk explained clearly what i was doing wrong, and how to do it right.

[@llothar68]

cmake has terrible documentation (no high level structuring and best patterns, even if you purchase their book). We need to forget about the early sins and make cmake 4.0 breaking compatibility with some ugly old stuff. And learning from the web now start to show its terrible weakness. You have no idea if you learn from an experienced person or how old the blog article is and if it still works. This is the big problem and it wasn't the first 10 years of stackoverflow but now references become terrible old and unusable but they are still top of google because thats how their algorithm works. I want back my text books to learn stuff like cmake and programming.

[@ali-kadar]

I am watching this talk after a CMake talk on modules in CppCon2020. I am a beginner with CMake and this talk by far is the most useful and easy to follow. Thank you for your effort.

[@CppCon]

You're very welcome!

[@michaelkohlhaas4427]

*Awesome presentation!!! Thanks!!!*

[@fdwr]

43:05 Oof, the more I read about and try to use CMake, the more I think we need another level of abstraction - an intuitive and clear to read build language to generate CMake definitions to generate build project files 😅.

[@TheLavaBlock]

Great talk

[@jessyhaykal2485]

Awesome presentation! Well done!

[@michaelkohlhaas4427]

Jessy Haykal You're still at Murex?

[@jessyhaykal2485]

I wonder who would ever leave Murex!

[@alexo989]

(hand-palm) - we are inventing problems to solve perceived problems . How did we come from structured and , in retrospective, relatively simple make files to this jumbled solution?

[@nitinshrivastava9071]

i am looking for my CPP depedency issues - where i am using OpenSSL upgrade and Other cpp Libraries this lecture helps me to understand cmake and how to use it

[@8Trails50]

bazel and buck perform the principles described in this talk pretty well. Very easy to catch circular dependencies because it won't build.

[@yogiwhy9531]

At 37:45 how to set or install libraries in Windows so that find_package() works? If the library doesn't have *.cmake file, what shall I do? Shall I write a CMakeLists.txt in the library folder? If I write the CMakeList.txt and build it separately, how to reference the compiled library to my project so that find_package() in my project works?

[@scouter84]

Thank you for the interesting talk that provided me with a lot of insights. When thinking about the contents, I came up with the following question: Let's assume the project would contain a module A which internally uses module B which implements logically lower stuff used by module A. Following the dependency inversion principle, module A would provide an interface which would be implemented by module B. Hence, module B depends on the headers of module A. A naive implementation of module A would instantiate code in module B when implementations of the interface in A abstracting B are needed. This in turn would result in a cyclic dependency. Is there a method to avoid this cyclic dependency besides dependency injection where a module C which depends on both modules A and B but not other way round can create instances of classes in module B and provide them to module A (directly or via an injected factory)?

[@kamalabuhenamostafa]

NICE...............

[@mnfchen]

At 37:03, why didn't he specify that the dependencies in target_link_libraries were PUBLIC/PRIVATE/INTERFACE? Didn't he say earlier you should be using those keywords always?

[@mwont]

Probably just forgot to write it on the slide.

[@Reichstaubenminister]

Exactly the problem I am trying to solve at the moment, by far my favorite talk on CMake! I like the simple examples that apply to use cases most smaller software projects will have, some of the other talks were more abstract and focused on scalability, which is not always necessary. The CMake documentation is quite good, but it would be nice if it gave you a few simple examples that could probably satisfy the needs of 90% of use cases. This talk is exactly what I felt it was missing. I like just using simple shell scripts for personal projects, but a serious project should always use something like CMake.

[@Reichstaubenminister]

Since he mentioned it: "focused on scalability" meaning in the enterprise, not when moving library code in a separate project or growing from one library to a few.

[@llothar68]

I'm now trying to get things done with qbs the build system from the Qt designers because they had 10 years to learn from the failures of cmake. And i have given up on good Xcode support from CMake. They still use a makefile on apple and just add some sugar around it but thats not integration and therefore a lot doesnt work at all (app signing, i18n ....)

[@thomashaines9922]

qbs is officially deprecated, and Qt have announced they will be switching entirely to cmake (deprecating qmake in the future)

[@dukajelvis]

yea indeed qbs is gone now and cmake still the main used build system... this really shows how complex is the subject here!

[@notjulesatall]

16:30 pkg-config was created for that very specific problem

[@jipe4153]

This walk was very good but I do feel its lacking and needs clarification on some ascpects.... On one side you explain why add_subdirectories(...) is an improper way of declaring a dependency between 2 modules. On the other hand you don't fully explain what the alternative is (IMO).... With the example of tcp_client --DEP--> libtcp , I wish you would have gone back to explain how to declare this dependency properly instead of hinting at something like ex: target_link_library(tcp_client libtcp). This gives some questions: -How do we inform tcp_client of the location of the libtcp module? -If not libtcp is not installed how do we inform tcp_client of where libtcp source code is so that it may be built? -Wouldn't be more proper to make an installable package out of "libtcp" and then use find_package to locate it? -If so how would that cmake system be organized?

[@gflegar]

It is an introductory talk, and yes, it does not cover the aspects you mention here. Fortunately, there's a good follow-up talk by Daniel Pfeifer that addresses these points: kzbin.info/www/bejne/mKS7fYCHa7yaf80 (also, there's this: gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1)

[@yezariaelll]

​@@gflegar gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1 just leaving this here, cause the link got corrupted with a parentheses

[@kippie80]

So French mocho. Still though, great stuff!

[@nickd3375]

Good, but beginner level modern CMake. If you've used target PUBLIC/PRIVATE/INTERFACE at all and know what it does, you're basically beyond the scope of this talk.

[@michaelkohlhaas4427]

I beg to differ. This talk is about CMake patterns and how to use it idiomatically. Look at all the CMake files out there: minimum requirement 2.8. That tells you all!

[@stephenl7797]

Who else hates CMake

[@LukeGlue]

What is your preferred choice?

[@garorobe]

@@LukeGlue msbuild