Oh No! More Modern CMake - Deniz Bahadir - Meeting C++ 2019

Oh No! More Modern CMake - Deniz Bahadir - Meeting C++ 2019
His CMake Talk from last year: • More Modern CMake - De...
Slides: meetingcpp.com/mcpp/slides
Survey: meetingcpp.com/mcpp/survey

[@mapron1]

I personally used object libraries until CMake 3.7-3.9 optimizations in Ninja generator, which made it more parallelizable. After that, no need for me to use them, as dependency propagation was freaked me out. One usage that comes to mind - efficient building both static and shared library on Windows, where you need different export attributes (so you can't just relink static into shared). Please share your use scenario of this beast :)

[@CT7ALW]

I want to make a note on adding header files to target_sources: For people that use the Qt library, the auto_moc only runs over header files and only on header files that are on the target_sources, so there is "positive implications" in doing so right today.

[@MrSamush]

The approach of importing an external library such as boost in a sub-directory using find_package and setting the target properties to IMPORTED_GLOBAL (slide 24) won't work well if you intend to use the project as a sub-project in a super-project where other sub-projects use the same trick. Is the only viable solution to this to use the more verbose include function instead?

[@alexreinking]

54:45 - I think you can `set(CMAKE_PROJECT_INCLUDE_BEFORE "")` inside of a function call that then does `FetchContent_MakeAvailable`.

[@seungin-cha]

34:00 Top-Level Project and Sub Project code is correct? my implementation and test does not find variables project_version, etc. In my case, project(MyRootProject) project(MyRootProject ...) thus, double command make it correct... Is there a mistake to me?

[@Deniz.Bahadir]

I am very sorry, but there I talked about a feature that is actually not implemented (and sadly probably will not be). Different than I originally thought the variable `CMAKE_PROJECT_INCLUDE_BEFORE` (and the similar named ones) are not loaded before the arguments of the `project` command are expanded. So this mentioned feature does sadly not work. (I thought I tested it before, but I obviously confused myself when testing that.) When I realized that (after my talk) I actually provided a merge-request to CMake's code (see: !4094 in cmake's issue-tracker) which enables the mentioned feature. However, as it seems, the maintainers of CMake are not happy with the variable expansion being deferred to after the file from `CMAKE_PROJECT_INCLUDE_BEFORE` was loaded. So, that will probably not make it into CMake. :-( However, you can still use the other way mentioned on slide 20 which explicitly `include`s the file directly before the call to `project`.

[@seungin-cha]

@@Deniz.Bahadir Thanks to your explanation very much :-)

[@PedroOliveira-sl6nw]

How can I use cmake version 3.15 with Travis-CI ? The last time I checked, they were using CMake 3.12 (when running Ubuntu Bionic)

[@PedroOliveira-sl6nw]

I am using VERSION 3.18.2 and for some reason CMAKE_PROJECT_INCLUDE_BEFORE is not working as described. I can set the variables and print them within the project-meta-info.in but CMake reports that "VERSION keyword not given or expands to nothing" (or something like that). And also, CMAKE_PROJECT_googletest-distribution_INCLUDE_BEFORE is not running. Anyone with the same issue?

[@Ryanfriedman96]

With the amount of time spent talking about the oddities of gtest CMake, he could have just issued a PR to fix em. At least it's much better nowadays in 2023. Seems so odd to me that gtest is subscribing to "Abseil Live at Head philosophy" but their CMake support is so behind.

[@mizuxseiha1609]

Please note when using target_source(), you should list your "public headers" as PRIVATE and use PUBLIC_HEADER properties instead of making them INTERFACE or PUBLIC is not what you'll want to do... see: github.com/Mizux/target_sources/issues/1

[@mapron1]

"Use the most recent version of CMake" from the authors of "Use the most recent version of compiler" and "just always update all your 140 dependent libraries to recent versions". That's ridiculous. Are we in C++ world? Words "supporting LTS distribution" also nothing to you? What "if possible" works for? "home project"?

[@Deniz.Bahadir]

As I mentioned in the talk, CMake is very good in using backwards-compatibility. So the latest version of CMake still supports very old CMakeLists.txt files. As I showed even CMakeLists.txt files written for CMake 2.6 are still working. And getting a more modern CMake executable should also be quite easy, as Kitware provides several compiled (and statically linked) versions through its website. If, however, you are stuck with an old system for which you do not want to or cannot update your CMake executable, why bother trying to compile a project written for a more modern CMake version at all? If downloading and running a statically linked executable (CMake) is too much of a hassle then compiling a modern project is probably too much to ask for.

[@anthonyvays5786]

it's a generator. no reason you should use an old version.

[@CT7ALW]

The cmake_minimum_required(VERSION x.x) dumbs cmake down to whatever you write in there as the version, so you can use whatever up-to-date version with whatever cmake script.

[@GC-qe8vc]

Using the latest CMake version will not affect whether your build artifacts (the final product) supports the LTS distribution. You can use the latest CMake version on your CI and build targets for the LTS you want to support. There's really no "excuses" when it comes to CMake , it's very different from choosing a newer stdlibc++.