Well, part of the reason you can't do coding well in CMake is that the "language" was designed by someone who didn't know anything about writing programming languages (neither imperative nor declarative), giving us a spaghetti machine full of quirks rather than an actual language. So I fully understand anyone squirming and complaining that they have to use it, but "unfortunately" it's currently the "best" (ie: the most prolific) thing out there. Just hope one day someone would make a CMake 2.0 with the help of someone knowing at least a little about how to write a good syntax.
@sugg57192 жыл бұрын
Try premake. You write the scripts in lua so it's a legit language.
@kuhluhOG8 ай бұрын
Yeah, the more I learn about CMake, the more it makes using Zig as a buildsystem for C/C++ projects look nice. (For those interested: The Zig compiler has clang integrated for both C and C++ and the buildsystem has explicit support for C and C++. And you write the buildsystem in Zig, a proper programming language.)
@amoghjain23 күн бұрын
does anyone have the ppt or pdf slides for this presentation?
@ecosta2 жыл бұрын
Nice talk! I learnt new ways of organising CMake code. I wish he had a talk about code-gen or showed how that looks for module consumers in large heterogeneous environments, like in Bloomberg.
@Deniz.Bahadir2 жыл бұрын
Great talk, loved it. A small nit-pick: You moved my both talks a year into the future. 😉 (I gave them in November of 2018 and 2019. But they appeared on KZbin a few month later.) Oh, and you said my last name just fine. 😄
@chandrasekharpbg3 жыл бұрын
why is this pointing to 2020 repository for slides. where is the github repository for cppcon2021?
@DebashishGhoshOfficial3 жыл бұрын
When will CMake emit linker_commands.json?
@bretbrown93832 жыл бұрын
There's no actual spec for this, for what it's worth. And nothing in particular that would consume it yet. Folks that want this can definitely open issues and CRs on the CMake project. Or submit papers to ISO SG-15 via the mailing list.
@petermuller6083 жыл бұрын
I'm torn about defensive argument checking. I personally like it as a user, however it makes your library forward incompatible
@bretbrown93832 жыл бұрын
Yeah, that's a good point. I personally find that we have more problems from misspelling (like TAGETS versus TARGETS) than forward-compatibility migration problems.
@petermuller6083 жыл бұрын
The main issue I'm facing with CMake is not allowing different Toolchain files in the same project. Thus it's really hard to support in source code generation while cross compiling. Thus adding certain CMake Modules will still change the way you have to compile your project, e.g. running the build multiple times with different toolchains in a specific order :( Edit: great talk nevertheless!
@bretbrown93832 жыл бұрын
Admittedly we don't do multiple flavors of cross compilation within the same project. If we did, we'd probably model those different compilations as completely different packages that, of course, had different build directories. We do offer a variety of toolchain files for different use cases to our projects, though. Especially to keep toolchain-specific logic out of CMakeLists.txt whenever possible.
@alexreinking Жыл бұрын
The best way to deal with source generators in CMake is to `export()` them from the build tree and try to `find_package` them before defining the targets. This way you can have a host-target build folder and a true-target build folder that imports the code generators from the host. When the host and target are the same, or CMAKE_CROSSCOMPILING_EMULATOR is set, nothing special needs to be done.
@MateuszAdamczyk3 жыл бұрын
It is sad, that in (almost) 2022 to build c++ project, You have to specialize in another language (CMake). Other languages move towards simple ini (declarative) file! CMake is unneded boilerplate and should be forgotten and not encouraged.
@bretbrown93832 жыл бұрын
Most other languages don't support all the different configurations that C and C++ do. I suspect we could get 70-80% of our projects on something very close to a config file metadata format. But the other 20-30% would include some must-have projects like oneTBB, LLVM, Boost, etc. I'm not opposed to the community moving that way, but we need to be careful about introducing "learning cliffs" via oversimple config files. If someone does need to, say, skip certain instrumentation modes on specific files, but only on certain toolchains, and that feature didn't exist, it would be a much, much more complex need than adding a few more lines to an existing CMakeLists.txt.
@DanielFSmith2 жыл бұрын
I think the comment at 45:30 perfectly sums up the major issue with cmake: "this could easily be in a make file".... Yes, it could. (For simple projects, anyway.)
@SimonToth832 жыл бұрын
This is a lovely summary of why I switched to Bazel. I'm not looking for another programming language, I want a build system. I understand why this is feasible for a company of Bloomberg size that can just implement whatever they need themselves.
@bretbrown93832 жыл бұрын
For what it's worth, the combination of qualities that CMake provides all ended up being essential to us: basically no dependencies (we don't have the JVM as a build bootstrap package), extensibility, ability to work around packaging bugs in the build system, ability to coexist with other build systems, etc. CMake really can handle just about any weird requirements you throw at it. And it can handle it in a distributed way... no need for a central CMake team with authority and time to burn down needed feature requests, etc. Bazel has matured a lot since we initially picked up CMake, so possibly it would have been a harder choice if we were to reconsider today. But Bazel was designed around monorepo workflows, so I'd expect some nontrivial work to support it with the same amount of quality as our CMake offering.
@italoaugustooliveira96643 жыл бұрын
Yet another cryptic talk about CMake.
@TheOnlyAndreySotnikov2 жыл бұрын
20 minutes into the talk, I still don't understand what a CMake module is. Leave alone what is a "modern" CMake module. I stopped watching. P.S. I've been an active CMake user for several years. Now I switched to Meson.