C++Now 2017: Daniel Pfeifer “Effective CMake"

cppnow.org
-
Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/boostcon/cppnow_pr...
-
While CMake has become the de-facto standard buildsystem for C++, it's siblings
CTest and CPack are less well known. This talk gives a lightspeed introduction into these three tools and then focuses on best practices on building, testing, and packaging. We will learn how to manage dependencies and export our libraries in such a way that they can be easily used by our clients. We will crosscompile for different platforms and run our tests in an emulator.
We will analyze code coverage and perform static and dynamic code analysis.
-
Daniel is an Electrical Engineer turned into a Computer Scientist. He works as C++ developer, system architect, trainer and guru for C++ and CMake. Daniel is the founder of the C++ user group in Munich. He is also an active contributor to CMake and knows some undocumented internals.
-
Videos Filmed & Edited by Bash Films: www.BashFilms.com
---
*--*
---

[@antoniocs8873]

<a href="#" class="seekto" data-time="3">00:03</a>:40 - Organization <a href="#" class="seekto" data-time="5">00:05</a>:05 - Commands <a href="#" class="seekto" data-time="5">00:05</a>:55 - Variables <a href="#" class="seekto" data-time="6">00:06</a>:45 - Comments <a href="#" class="seekto" data-time="7">00:07</a>:35 - Generator Expressions <a href="#" class="seekto" data-time="8">00:08</a>:20 - Custom commands <a href="#" class="seekto" data-time="9">00:09</a>:08 - Custom command: Function <a href="#" class="seekto" data-time="10">00:10</a>:27 - Custom command: Macro <a href="#" class="seekto" data-time="11">00:11</a>:25 - Custom command: Guideline <a href="#" class="seekto" data-time="11">00:11</a>:50 - Evolving CMake Code <a href="#" class="seekto" data-time="12">00:12</a>:22 - Deprecate CMake commands <a href="#" class="seekto" data-time="12">00:12</a>:45 - Deprecate CMake variables <a href="#" class="seekto" data-time="13">00:13</a>:39 - Evolving CMake Note <a href="#" class="seekto" data-time="13">00:13</a>:47 - Targets and Properties <a href="#" class="seekto" data-time="14">00:14</a>:55 - Targets and Properties Notes <a href="#" class="seekto" data-time="17">00:17</a>:22 - Imagine Targets as Objects <a href="#" class="seekto" data-time="18">00:18</a>:23 - Commands to forget <a href="#" class="seekto" data-time="19">00:19</a>:07 - Example <a href="#" class="seekto" data-time="20">00:20</a>:37 - Don't use CMAKE_CXX_FLAGS <a href="#" class="seekto" data-time="22">00:22</a>:07 - Build Specification and Usage Requirements <a href="#" class="seekto" data-time="23">00:23</a>:09 - Use target_link_libraries() <a href="#" class="seekto" data-time="24">00:24</a>:15 - Use target_link_libraries() example <a href="#" class="seekto" data-time="28">00:28</a>:09 - Pure usage requirements <a href="#" class="seekto" data-time="29">00:29</a>:16 - Don't abuse requirements <a href="#" class="seekto" data-time="29">00:29</a>:33 - Project Boundaries (how to use external libraries) <a href="#" class="seekto" data-time="30">00:30</a>:55 - FindFoo.cmake <a href="#" class="seekto" data-time="33">00:33</a>:30 - FindPNG.cmake (massive file) <a href="#" class="seekto" data-time="34">00:34</a>:35 - Guideline on Find <a href="#" class="seekto" data-time="37">00:37</a>:35 - Export your library interface <a href="#" class="seekto" data-time="39">00:39</a>:31 - Export your library interface (continued) <a href="#" class="seekto" data-time="43">00:43</a>:40 - Export the right information <a href="#" class="seekto" data-time="44">00:44</a>:48 - Creating Packages <a href="#" class="seekto" data-time="44">00:44</a>:59 - CPack <a href="#" class="seekto" data-time="45">00:45</a>:44 - Write your own CPackConfig.cmake <a href="#" class="seekto" data-time="46">00:46</a>:18 - CPack Secret <a href="#" class="seekto" data-time="46">00:46</a>:50 - Packaging multiple configurations <a href="#" class="seekto" data-time="48">00:48</a>:58 - Package Management <a href="#" class="seekto" data-time="49">00:49</a>:10 - Requirements <a href="#" class="seekto" data-time="50">00:50</a>:31 - How to use external libraries <a href="#" class="seekto" data-time="50">00:50</a>:51 - Do not require any changes to my projects <a href="#" class="seekto" data-time="52">00:52</a>:08 - Use the your public interface <a href="#" class="seekto" data-time="52">00:52</a>:35 - Guideline on export <a href="#" class="seekto" data-time="52">00:52</a>:38 - The toplevel super-project <a href="#" class="seekto" data-time="55">00:55</a>:38 - How does that work? <a href="#" class="seekto" data-time="58">00:58</a>:09 - CTest <a href="#" class="seekto" data-time="58">00:58</a>:13 - How to run <a href="#" class="seekto" data-time="60">01:00</a>:35 - CTest guideline <a href="#" class="seekto" data-time="60">01:00</a>:46 - Filtering tests by name <a href="#" class="seekto" data-time="61">01:01</a>:37 - CTest guideline <a href="#" class="seekto" data-time="61">01:01</a>:41 - Fail to compile <a href="#" class="seekto" data-time="63">01:03</a>:03 - Running crosscompiled tests <a href="#" class="seekto" data-time="63">01:03</a>:46 - Run tests on real hardware <a href="#" class="seekto" data-time="64">01:04</a>:03 - Cross Compiling Toolchain.cmake <a href="#" class="seekto" data-time="64">01:04</a>:44 - Toolchain guideline <a href="#" class="seekto" data-time="64">01:04</a>:58 - Static Analysis <a href="#" class="seekto" data-time="65">01:05</a>:11 - Question <a href="#" class="seekto" data-time="66">01:06</a>:15 - How do you treat build errors? <a href="#" class="seekto" data-time="66">01:06</a>:30 - Treat warnings as errors! <a href="#" class="seekto" data-time="66">01:06</a>:54 - -Werror causes pain <a href="#" class="seekto" data-time="67">01:07</a>:36 - Better: Treat new warnings as errors <a href="#" class="seekto" data-time="68">01:08</a>:54 - Pull out all the stops! <a href="#" class="seekto" data-time="69">01:09</a>:28 - Target properties for static analysis <a href="#" class="seekto" data-time="70">01:10</a>:36 - Scanning header files <a href="#" class="seekto" data-time="71">01:11</a>:20 - Guideline <a href="#" class="seekto" data-time="75">01:15</a>:17 - Create associated source files <a href="#" class="seekto" data-time="75">01:15</a>:23 - Enable warnings from outside the project <a href="#" class="seekto" data-time="76">01:16</a>:03 - Supported by all IDEs <a href="#" class="seekto" data-time="76">01:16</a>:28 - Finish <a href="#" class="seekto" data-time="78">01:18</a>:58 - Personal Wishlist

[@henryborchers4710]

This is by far the best CMake video on the internet. After watching this, I went back and cleaned up my terrible CMake build scripts. I really hope this isn't the only good video we will ever get on CMake.

[@helmesjo]

Haha, just got the same feeling! Got some fixing to do!

[@peppybocan]

Yeah, CMake is lacking a good source of examples and tutorials. A lot of that is just googling or stackoverflow searching.

[@charityisland]

A great repository for examples covering many scenarios with GREAT commentary: github.com/ttroy50/cmake-examples

[@FlorianWolters85]

Altthough the project you referenced covers a lot of of topics, it does not consequently use Modern CMake. Example #1: add_library is explicitly called via STATIC/SHARED (one should use BUILD_SHARED_LIBS) Otherwise one can get problems with transitive dependencies. Example #2: Variables from the FindBoost module are used instead of targets. etc. I've found CGold (cgold.readthedocs.io) very useful, though the author sadly didn't finish the documentation. Nonetheless the information included in CGold is very valueable, imo.

[@leduke79]

Also a nice read, linking to this video: gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1

[@tomkirbygreen]

Late to the party but adding my +1, this talk is pure gold!

[@JoshPeak]

This highlights the lack of good onboarding tutorials for CMake. I have just been ramping up on all the easily accessible tutorials but they target 2.8x generation but the latest CMake 3.8.x is a different paradigm. It is updating faster than the documentation and tutorials. Definitely need more talks like this. I'm off to rewrite my CMake scripts.

[@llothar68]

A big problem of almost everything in developer land at the moment. The documentation pages is fine, but again as usual, it is lacking the overall design explaination document.

[@AlexanderWhillas]

Yes! The offical CMake tutorial is still in the old paradigm!? cmake.org/cmake-tutorial/

[@FlorianWolters85]

Yes, it's still the same old tutorial. Kitware should really remove that (together with the outdated wiki - I refuse to link to it here) and link to the latest documentation cmake.org/cmake/help/latest instead. Can anyone tell something about the quality of the latest version of the "Mastering CMake" book covering CMake v3.1? I am afraid that book is also outdated and contains a lot of information related to v2.x.

[@llothar68]

What is CMake 3.1? This is still ages old. We are at 3.10 at the moment.

[@FlorianWolters85]

True. CMake v3.1 has been released on 2014-12-17, so it is almost three years old. Since I haven't read the book, I can't judge it. The current stable version is 3.9.4 though, to be fair.

[@ozancansel]

Unbelivable content, just thank you

[@svizcay]

Excellent video! (Video/audio quality, content, etc). Internet is full of obsolete documentation about CMake. I would really love if people start writing CMake files using this modern approach.

[@DFsdf3443d]

i once spend 2 hours trying to figure out how to append items to a list in cmake

[@abelmqueralto]

Cmake is not for you

[@AnthonyDentinger]

😂😂 Nice one!

[@manchul]

Holy shit. This was way over my head. I personally don't think this is a tutorial video into CMake. It felt more like "hey CMake 2.8 guys. This is how we changed in 3.8". When this comment is over 1 year old, and if CMake is still version 3, reply to my comment whether I can do CMake. As of 2018 October 11, the 3.13.0-rc1 is ready for testing. I'll go grab some tears and look for version-friendly CMake tutorial first.

[@Danielle_1234]

It's videos like this that remind me why Meson has been getting so much headwind as of late. CMake and Meson are so similar, except that Meson has great guides for learning from the ground up. If this video is too complex, Meson might be the ideal way to learn CMake.

[@jmac217x]

The people in the audience seem like they're trying to fight his recommendations every step of the way lol I'm glad to see most projects have taken this advice into consideration in the years since this talk

[@bjbegui]

"Still use a build system for header only libraries"..... YES

[@JimmyMcG33]

writing c++ isn't so bad, but getting an executable out of it makes me want to smash my keyboard. the learning curve for a newcomer is just insane.

[@marcusmors8485]

<a href="#" class="seekto" data-time="1647">27:27</a> does it have to repeat the name after the double colon or not? I haven't understood that part.

[@kevinaud6461]

This guy makes nice looking slideshows

[@richardvonlehe4581]

This video is incredibly helpful. Seriously, who downvoted it?

[@iMaxos]

this presentation makes me want to write makefiles again

[@rajaravivarmar]

I was trying on and off to keep in touch with C++ for about 7 years, despite hating some of its language features like I have to watch a 90 minutes video on trivial things like object initialization. This coupled with confusing features like collapsible references etc, lack of library management tools etc kept me at the bay. Then latest projects started using this insanity called CMake. That was the final nail in the coffin.

[@videojeroki]

I understand the need of not deprecation, but i would love that cmake and c++ compilers using optional deprecation so recent projects can be forced to use the lastest/modern features.

[@AnthonyDentinger]

That's absolutely possible, but to do that right now you have to 1) setup the appropriate compiler warnings and add "-Werror"/"/WX" in your CI, which will already be very helpful, and 2) integrate clang-tidy (see 1:15:23) into your CI setup. If I understand the zillion CppCon videos I watched, the reason of the comittee to take time making this kind of behavior standard is that the industry everywhere needs the many immense and critically important existing codebases that make use of bad C++ stuff. So they want to avoid breaking compatibility as much as is reasonable, so they often have to take the careful approach. The standard comittee keep saying that eventually the standard will require, by default, for compilers to disable the bad bits of C++ and only allow them when explicitly enabled somehow. To be sure, it's been a number of years they've been saying that, but at least I'm incredibly grateful we have things like compiler warnings and nowadays have clang-tidy. This requires some setup, which is annoying, but at least for a real-world project you *_can_* get the safety if you care enough about it or if you're interested enough about writing good C++. For example, "-Wmisleading-indentation" warns about, well, misleading indentations, such as in the case of the famous 'goto fail' Apple bug. With both "-Werror" and "-Wmisleading-indentation" in your CI, you will never let misleasing indentations through to production again --at least not on GCC or Clang, since MSVC would require different flags! In a way, because it's the project that chooses its own language safety rules via compiler warnings/clang-tidy checks, it means the project is able to enforce its own set of guidelines if needed. For example, a project's team might decide to implement a clang-tidy check that warns on every use of known heap allocation APIs (new/delete/malloc/free/my_custom_alloc/etc.), which makes sense if the project is meant to run on embedded systems that are not required to have a heap at all. The team might add this check to their CI setup, with warnings treated as errors inside the ".clang-tidy" file, to automatically reject any pull request that attempts to add a call to one of these allocation/deallocation APIs. This means, in a way, that they've just implemented their own "version" of C++, as if they had added the words _"Any use of new/delete/etc. is ill-formed"_ at the end of the C++ standard that they're using.

[@yanyonggang3625]

great👍

[@SethKingofthenerds]

I worked with a medium sized code base that uses recursive Make. I am having difficulty selling(older C-developers) anything to allow parallel compiling. Any tips or tools on moving something like this to CMake. Love Clion!!!

[@llothar68]

Why is using make in parallel compiling a problem? It does this very well with -j option? Selling CMake is hard if you are not multiplatform and/or users want use modern IDE's.

[@PeterPetrakis]

The best way to convince salty old engineers is to dig in, do the work, show that it works, and also show how it can improve their lives (i.e. adding value). So for example, moving to Cmake would make it easy to import the project into qt creator and use a graphical debugger that really works. Adding the compile_commands property will enable code completion plugins like YouCompleteMe, it's also a parseable index of how an object was really compiled, which makes it really easy way to track down build flag disputes, or just copy paste to rebuild an object on the CLI. Transparent use of ninja to parallelize the build. Having multiple build targets for Clang's static analyzers that improve code quality. The list goes on.

[@deepanmuthusamy9735]

could anyone suggest me a github project with clean cmake files? Thanks in advance.

[@michaelliao5027]

What happens if all your target needs to link to the same library, wouldn't it be easier to use `link_libraries()` instead of `target_link_libraries()`

[@AnthonyDentinger]

Not really. It's like using global variables in C/C++: it makes it easier to _write_ the code intially, but not to _read_ it and not to _change_ it later. As the CMake project grows, I'd much rather read self-contained code that does one thing and one thing only, even if that code is a bit longer (like a long-ish function that only has local variables), rather than having to run through dozens of CMake files that all perform global operations like link_libraries() everywhere (like a somewhat smaller but terrible function that keeps reading/writing global variables from lots of different places). It's definitely not that bad on small projects, but for larger ones it can get quite terrible! And I personally value the little sanity I have left :') Plus, with link_libraries() you don't get the incredible automatic dependency transitivity that target_link_library() provides and that this presentation talks about. With link_libraries(), you have to specify every single library you depend on, and you also have to know what flags and include directories, etc the libraries you use need. So if your library needs library A, which internally needs library B, with target_link_library() you don't (shouldn't) need to know that A happens to need B, and you also automatically inherit the correct include directories, compiler flags, etc. You should only need the target_link_libraries() and that’s it. With link_libraries() though, you will need to specify both A and B, which is annoying if you one day upgrade library A and A now needs another library called C. Plus, you will have to figure out yourself which flags A and B need, and which directories their headers are, and add all of them yourself.

[@victoreijkhout7115]

I could really use a tutorial before I grok this lecture. The only easy tutorial that I found so far has taught me everything that this guy says I shouldn't use. Harumpf. So where is the gentle introduction to the right way to do things?

[@HiAdrian]

A lack of up-to-date documentation is the big issue with CMake as you will have read many times already, but maybe these two sites can help a bit: cliutils.gitlab.io/modern-cmake/ cgold.readthedocs.io/en/latest/

[@jonnykopp]

@@HiAdrian Thank you very much for sharing

[@spades10]

I don' understand why shouldn't we require ISO C++17 for example, but lambdas etc. I want to use VS2017 in C++17 mode, and passing one of the features I need just to get everything seems kinda hacky. I would much rather say I want ALL of C++17 and continue building my library.

[@Hilborn90]

CMake supports this since 3.8 via cxx_std_17: cmake.org/cmake/help/v3.8/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html

[@FlorianWolters85]

Exactly, just use something such as target_compile_features(mylib PUBLIC cxx_std_11) (cmake.org/cmake/help/latest/manual/cmake-compile-features.7.html#requiring-language-standards). I find it much easier to use too, since I do not need to manually synchronise the required features in the build file with the features used in the C++ source files.

[@MrSamkots]

Great video...! I think, learning CMake is more difficult than learning C++ itself :/ Even if C++ is difficult, we at least have definitive learning material for it...

[@thegod3500]

If i want to trigger my build system to see a new file from file(GLOB) i just manually re invoke Cmake to 'update' my build system, We need do that even without file(GLOB) after the file was added. So, i don't see nothing bad in file(GLOB)

[@HarinduDilshan]

How is it different from updating cmake everytime?

[@thanatos454]

​@@HarinduDilshan It is very different. One requires you to keep a running list of files you add/remove in your head as you work on a new feature(or use git to help a little, granted) or preemptively add a bunch of empty, anticipated files. Just so you can then type out those new files by hand into the correct spots your CMake. All of that is very error-prone and distracting(breaking flow). While file(GLOB) just requires you to manually re-enter the same command. Literally Up Arrow, then Enter in most cases. None of the reasons I've heard for while they can't get rid of this issue make any sense either. If they are already generating make files that automatically retrigger when CMakeLists changes, why can't they do the same thing with another file called SourceList that are just plain old lists? That way IDE's can easily just auto-populate the list, adjusted as their project tree changes. Someone, please tell me why this wouldn't work.

[@vetirtal1168]

@@thanatos454 In cmake 3.12 they added CONFIGURE_DEPENDS to file(GLOB ...) so it can check at build time, so you don't even have to manually check. They say it adds to the build time though. I disagree with you that the typing of the files is error prone because you'll generally know if a file is not recognized anyway.

[@voltairespuppet]

Would it make sense to have an "always call cmake" first to the target build system to make sure it is always up to date especially for globing calls? Store the globs in a sorted file for comparison, only update if there is a change. Seems like monitoring directory for new content is a legitimate set of functionality for a build system and for a tool supposedly to help bridge gaps between them.

[@AnthonyDentinger]

@thegod3500 I think there are a lot of people on both sides of the issue. The CMake maintainers, and others generally seem to strongly discourage file(GLOB) (even with the newer CONFIGURE_DEPENDS) for source files to allow supporting all generators and for a number of other reasons, while many others encourage it to avoid forgetting stuff.

[@llothar68]

I have written a build system on top of the cmake buildsystem.

[@FlorianWolters85]

I've did the same. I've added a CMake convention-over-configuration framework using CMake modules that is added to each of my C++ components as a submodule (each component is either one application or one library together with optional tests and examples). With that approach I only have a very slim CMakeLists.txt that does contain the dependencies and source files only. Yes, I need to use variables to achieve this, but at least I do not have to maintain copy-&-pasted boilerplate code. I've already added integration (using strong assumptions, but still being flexible) for Doxygen, Protocol Buffers, Google Test, cloc, Flawfinder, etc. Future tasks include addition of other static analyse tools as well as code coverage and so on. IMO it's sad that everyone has to built its own solution and that CMake does not provide (optional) stronger assumptions how-to structure and build a C++ component. Package Management is also still an issue.

[@LetTheNewDayBegin]

<a href="#" class="seekto" data-time="705">11:45</a> "Create macros to wrap commands that have output parameters. Otherwise create a function. " This isn't very clear at first sight. Because if you know the names of output variables and wants to foward it to the caller you can just set PARENT_SCOPE. I'd say you only need the macro when you don't know what the names of output parameters are and you want to forward them to the caller. An example would be all the global variables that come from calling find_package.

[@AnthonyDentinger]

I think I agree. These are, of course, guidelines, not absolute rules. However, using a macro is still avisable in many cases even when you do know what the output variables are, since mis-setting variables is a bug that's always around the corner in CMake, especially if you want your codebase to remain actively developed for many years and you/someone might add/remove variables someday.

[@kaipada_]

is it okay to set c++ standard like this set(CMAKE_CXX_STANDARD 11)

[@robertdailey7614]

Yeah I do this as well. You can also use the meta-feature: target_compile_features(Foo PUBLIC cxx_std_11)

[@llothar68]

CMake still does not works with the I18N and L17N features of XCode.

[@JohnDogget1]

At kzbin.info/www/bejne/mKS7fYCHa7yaf80 I believe you should use ARGV0 instead of ARG0 (see cmake.org/cmake/help/latest/command/macro.html )

[@ecarew2]

This is rather confusing as an onboarding video. Is there a good 3.x tutorial document or book? The talk is frustrating in that it introduced some powerful concepts of CMake without enough background to employ them.

[@jflopezfernandez]

<a href="#" class="seekto" data-time="2007">33:27</a>

[@code-dredd]

Ah yes, everything is so "straightforward" that we need an obscene amount of explanations before being able to setup something simple. This presentation is clearly aimed at people who are already familiar with CMake. If you're just trying to figure out your particular situation and found that you need to learn CMake, this presentation won't help you much. You're better off finding something more tutorial-like... except that most content out there is giving obsolete "advice" for obsolete CMake versions... It's amazing that all of this crap has not been automated as part of IDEs in some way. Really... wth.

[@erikprantare696]

Not all people use fully fledged IDEs with bells and whistles, I e.g. use vim for editing and cmake for building.

[@LimitedWard]

Agree 110%! I would love to have a command line tool which entirely automates this with best practices. Something like: > cmake-tool init cmake-tool create cmake-tool add-package

[@pavankmanjithaya]

<a href="#" class="seekto" data-time="1420">23:40</a>

[@sergeyrykovanov6396]

Never had good experience with CMake - it is not really "cross-platform" - you always need to tweak something when you change from Linux to MacOS to whatever you use :(

[@manualdidact]

This fellow clearly knows what he's talking about and could be considered a subject matter expert, but it seems to me he's an utterly incompetent presenter. He utilizes details before he describes them, goes off into unnecessary tangents without making it clear he's doing so, and presents sections of script files without labeling them or mentioning where they go, all of which force the confused audience members to interrupt with questions that should have been unnecessary. I can see this being useful and informative to a certain subset of CMake users who are sufficiently up-to-speed to intuitively understand the contextual information he leaves out (eg. what file he's showing the contents of on his slide), but there's an inconsistency of assumption of prior knowledge, given that the talk starts out with very basic syntax -- anyone who could benefit from the first few minutes will get nothing from any of the content beyond that. Despite having used CMake 3.x for over a year now I am so far understanding very little of the bulk of this talk. If he wants to promote CMake as excessively baroque and complicated to those not already well-versed in its use, this presentation works well for that purpose.

[@ninepoints5932]

Having watched this in its entirety, I respectfully disagree with you wholeheartedly and think his presentation still is great. The talk is "Effective CMake". Not "Cmake 101" and your point about this having useful information for CMake users "sufficiently up to speed" is completely correct and seemingly intentional. If you've used 3.x for over a year and understand "very little of the bulk of this talk" I don't believe any talk will help you.

[@TimClemons]

Wow, C++ developers interrupt a lot. Let the man talk!

[@Lisekplhehe]

If something is unclear - ask. Because if you don;t you could fail do understand the rest. And then we have developers who are afraid to admit they dont understant and project that onto new people creating more and more problems with less and less maintainable solutions.

[@max0x7ba]

CMake is dominant and plain horrible. Its "language" is an example of how to not design programming languages. It is a good idea to switch to Lua, Python, JavaScript or any other modern scripting programming language. And yes, I want Turing completeness in the build system.

[@the.real.ipatch]

wow dem sounds like fighting 💪 words 😤

[@williamchamberlain2263]

Bloody hell; why're you defining another language to compile the language you actually care about? And please, C++ community, fix your versioning standards: [major.minor.patch.whatever-the-hell-you-want] is _not_ hard.

[@AnthonyDentinger]

No! I will use 1.a.dev-alpha for the rest of eternity! XD

[@inanitas]

Can't wait for Rust to replace C++ in all new developments. The dependency management of C++ is primitive and out of date. There are no benefits. C++ itself also struggles with legacy design problems. There is no valid reason to use C++, except for "the project already is C++".