I want to upvote this for solid info, but I want to flag it so fewer people have to know about CMake. It blows my mind that experienced software developers would develop yet another pseudo-language DSL vs creating a portable library (python, java, go, whatever) that has a sensible interface.
Creating your own build tools becomes unmaintainable by anyone else. People do it all the time, and pay the price when they have to change their builds. There is a reason CMake is used by a lot of projects, it's not somehow due to everyones incompetance.
Everything You Never Wanted to Know About CMake
11–20 of 91 posts
Re: Everything You Never Wanted to Know About CMake
#12Earlier quoted context omitted.
I'm not sure what you mean. If for whatever reason I need to set up a big C/C++ application so that it can compile on diverse systems, CMake is one of my best bets for getting that to happen. If anyone would like to suggest a better option I would gladly switch, but as it stands I think CMake is pretty useful to know about.
Bazel works very well for C++ applicatios. Cross platform builds are well supported.
Re: Everything You Never Wanted to Know About CMake
#13Re: Everything You Never Wanted to Know About CMake
#14I want to upvote this for solid info, but I want to flag it so fewer people have to know about CMake. It blows my mind that experienced software developers would develop yet another pseudo-language DSL vs creating a portable library (python, java, go, whatever) that has a sensible interface.
Creating your own build tools becomes unmaintainable by anyone else. People do it all the time, and pay the price when they have to change their builds. There is a reason CMake is used by a lot of projects, it's not somehow due to everyones incompetance.
Re: Everything You Never Wanted to Know About CMake
#15I want to upvote this for solid info, but I want to flag it so fewer people have to know about CMake. It blows my mind that experienced software developers would develop yet another pseudo-language DSL vs creating a portable library (python, java, go, whatever) that has a sensible interface.
Re: Everything You Never Wanted to Know About CMake
#16Earlier quoted context omitted.
Creating your own build tools becomes unmaintainable by anyone else. People do it all the time, and pay the price when they have to change their builds. There is a reason CMake is used by a lot of projects, it's not somehow due to everyones incompetance.
If the build system was a library called from a popular scripting language, it would only take a few minutes of reading the API docs before it builds could be modified. Also, there is a niche for new build systems: one-off projects that "don't matter." If you want to introduce a new build system, your first target market could be throwaway point-a-to-point-b projects and then you could expand outwards from there.
From what I've seen cargo gets most of the parts right. You can have a programmatic pre-build script bit can't take over the whole building process.
Re: Everything You Never Wanted to Know About CMake
#17I want to upvote this for solid info, but I want to flag it so fewer people have to know about CMake. It blows my mind that experienced software developers would develop yet another pseudo-language DSL vs creating a portable library (python, java, go, whatever) that has a sensible interface.
Probably one of the biggest features in a configure/build/packaging software package is ubiquity, IMO. Ideally C/C++ would have had a prescribed-but-not-required thing like cargo/setuptools/go get/etc. IMO CMake is probably the least bad offering these days.
Re: Everything You Never Wanted to Know About CMake
#18Re: Everything You Never Wanted to Know About CMake
#19Maybe just use python/etc to write a better wrapper for Makefiles? There are so many build system to choose these days.
Re: Everything You Never Wanted to Know About CMake
#20I want to upvote this for solid info, but I want to flag it so fewer people have to know about CMake. It blows my mind that experienced software developers would develop yet another pseudo-language DSL vs creating a portable library (python, java, go, whatever) that has a sensible interface.
I think a build system should always allow to convert its build description to a bash file that contains a more or less linear account of all actions needed (without support for incremental builds). Now if every library were distributed with such linear script, the user is guaranteed not to get stuck in obscure build problems. And of course, they can first try the official incremental route (cmake in this case) if th…
Most of the build issues that a user will face is there system not matching the developers.
We can have pretty complicated logic (arbitrary logic in most build systems) for probing the build system, and much of this logic will inevitably get lost when compiling a linear script.
Once you put all of the complexity in the compiled script, I don't think you've gained anything over "make clean ; make" (or equivelent)