16 ms·

It still boggles my mind that CMake was the thing that won for the next generation of build systems. Its syntax is probably even worse than bash (except that i

by wheels 8y ago

It still boggles my mind that CMake was the thing that won for the next generation of build systems. Its syntax is probably even worse than bash (except that it didn't have decades of compatibility to blame that on), making it the single worst language I've ever written code in. I struggle to understand how one could sit down to create a language and come up with something that bad. There was apparently at one point effort to replace its frontend with Lua, but that sadly never took off. (I, like everyone else, still hold my nose and use it, but man ... like ... bwa?)

weberc2 8y ago
I absolutely agree. This is the number one reason I don't do any serious development in C or C++. Here are some grievances that come to mind: * Pretty much everything is a string * One giant namespace with no notion of imports * No sane dependency management; just uses whatever is laying around the system * IIRC source files have to be listed in the CMake file individually (or at least that's what I recall to be the best practice) * Everything is a one-off function. [Seriously, CMake comes with functions for Qt projects][0] and other popular libraries. * It's supposedly cross-platform, but you need to take care if you want it to generate sane, usable VS solution files. IIRC, it would create a VS project for every subdirectory or source file by default. * I forget whether CMake itself is slow as hell or if it just generates super slow Makefiles, but in either case, it is painful [0]: https://cmake.org/cmake/help/v3.0/prop_tgt/AUTOMOC.html https://cmake.org/cmake/help/v3.0/prop_tgt/AUTOMOC.html
- tom_ 8y ago
  Listing source files individually is what you're supposed to do, because not all build tools support globbing for files. To support this properly, cmake would need to re-run on every build to regenerate the files list... well, it's probably doable, with some work, but I expect there's just not the demand, I expect because most people are like me and would prefer to list their source files out by hand so they know where they stand. The Visual Studio projects it creates, at least for my projects, have a VS project per target. That's just how Visual Studio works. You do tend to end up with a lot of projects in one solution this way, which is something most people don't do when setting projects up by hand - but with CMake picking up the strain there's no reason not to. (It's also very convenient for running tests in the debugger. One target per test, select it as the startup project, and off you go.) As for makefiles, I haven't noticed CMake's being noticeably slower than any others I've seen, though I'm sure it's possible. They are rather larger than most Makefiles. (If you're able to switch to Ninja, that comes recommended.)
  - dottrap 8y ago
    I've never had a reason to suspect CMake's Makefiles are slower than others. I've converted projects from Autotools to CMake and CMake was always miles ahead faster. I recently switched to using CMake's Ninja generator. I've been shocked at how much faster it is than Makefiles, even for tiny projects.
    - isaachier 8y ago
      This benchmark would imply that isn't usually the case: http://david.rothlis.net/ninja-benchmark/ http://david.rothlis.net/ninja-benchmark/.
      - zik 8y ago
        I just converted a large project's build system from Makefiles to meson+ninja. The ninja part is significantly faster than make was because it's keeping all the processor cores busy all the time which make doesn't do.
        pletnes 8y ago
        alias mj=‘make -j $(nproc)’ works like a charm on all my CMake projects. Keeps the cores warm!
        jcelerier 8y ago
        Ninja does this by default but additionally has a much lower overhead on incremental rebuilds.
        cbcoutinho 8y ago
        you can also set MAKEFLAGS=" -j $(nproc)" and keep using `make` as your would normally
        pletnes 8y ago
        It’s nice to drop back to serial compilation when debugging IMHO. Sometimes one header bug causes two errors with interspersed output in parallel builds.
pornel 8y ago
The problem I have with CMake & autotools is that every project writes their build process from scratch, and everyone does things slightly differently making their project a snowflake. Certain platforms, compilers, and dependencies need special handling and workarounds, and this knowledge isn't shared and has to be repeatedly rediscovered by every project. Rust's Cargo, perhaps accidentally, has found a fantastic solution to this. The build process itself is built out of packages. I don't have to know how configure MSVC compiler, I just use an existing crate for it. I can use existing package to find and configure libpng — the work to handle its own quirky pkg-config replacement has been done once, and now every downstream project can benefit from it. Package manager in the build system may sound strange, but it's actually fantastic. It works so well that I switched my C projects to Cargo to be able to build them on Windows.
- bluejekyll 8y ago
  I keep considering that we might want to port Cargo to support other languages... It's better than nearly everything out there that I've ever used.
  - jcelerier 8y ago
    > I keep considering that we might want to port Cargo to support other languages... It's better than nearly everything out there that I've ever used. I don't think that this would solve anything. A big problem for instance is maintainers who insist in keeping compatibility for totally obsolete stuff - see for instance zlib which clings on DOS compatibility, or Nethack which just started to use ANSI C features in the latest release ; before this they were on K&R C. As a result build sytems are terrible since they have to handle so many edge cases for obsolete compiler vendors, Watcom C & friends for instance. Rust code doesn't have this kind of legacy to handle.
    - bluejekyll 8y ago
      For C it’s not as obvious how this could be accomplished, but it would be possible. There are lots of Rust projects that embed C today, and add C flags for the LLVM. The language I was really thinking of was Java, where Cargo is far superior to maven. I’ve never had time, but what I’ve thought would be neat is to take a Cargo.toml file as input, and then generate the maven files from that, like Cargo.lock files in Rust.
TillE 8y ago
The language itself isn't great, but I don't think that's the main problem with CMake. The whole structure of the thing is like having a dump truck pour a giant pile of tools in front of you. It's all in there somewhere, but good luck figuring out which ones you need.
- berkut 8y ago
  Out of interest, how's this any different than other build systems like SCons, Waf? Even working out stuff like string substitutions in Make can be confusing at times, in terms of the syntax required IMO.
slavik81 8y ago
The language isn't great, but I have never spent more than a few hours trying to figure out how to do something in CMake. In other build systems, I've had to give up on some features after dozens of hours of trying. CMake is ugly, but it won because it works.
- lfowles 8y ago
  I'm still not convinced there's a good way in cmake to pull in and compile external libraries as dependencies. I know it can be done via a superproject method but that's a lot of boilerplate for something that should be straightforward. Everything else is simple and easy until I butt heads with that issue.
  - berkut 8y ago
    In my experience, ExternalProject_Add() isn't a lot of boilerplate. You specify the source, target dir, and other stuff can be optional.
    - lfowles 8y ago
      It's been a while since I've done this kind of CMake in anger, but I recall my main gripe with ExternalProject_Add is that it can't leverage that the external project is a CMake project and I still end up hard coding paths.
      - svalorzen 8y ago
        Not sure if this can help you, but I simply use function (AddDependency name) add_subdirectory(${PROJECT_SOURCE_DIR}/deps/${name}) include_directories(${PROJECT_SOURCE_DIR}/deps/${name}/include) endfunction (AddDependency) And then use git submodule to clone all the dependencies I need in the deps folder. Everything then works automagically (assuming that the dependency is built through CMake).
  - isaachier 8y ago
    Check out https://github.com/ruslo/hunter https://github.com/ruslo/hunter for a fantastic CMake package manager built to solve this issue.
bch 8y ago
What boggles my mind is that it was conceived on a project (medical imaging, iirc) where they were using Tcl as an embedded language, decided to create a new build system that needed an embedded language and... decided to write one from scratch? I would have love, love, LOVED to see Tcl in that space.
- jzwinck 8y ago
  They thought if they used Tcl, CMake would not have enjoyed widespread adoption: http://www.aosabook.org/en/cmake.html http://www.aosabook.org/en/cmake.html To me, the CMake language is the only part that keeps me on the lookout for a CMake replacement.
- gaius 8y ago
  I would have love, love, LOVED to see Tcl in that space. 100% agree, a Tcl based build system would be a dream come true. I wonder why they thought it would not enjoy widespread adoption. Plenty of Tcl-based systems did, after all, and it's only because of fashion now that people aren't still using it.
  - bch 8y ago
    There is smake[0], which I use a lot, and lots of room to grow with (I.e.: dig in and figure out idioms), but Tcl/cmake could have been very interesting. [0] http://chiselapp.com/user/Setok/repository/smake/index http://chiselapp.com/user/Setok/repository/smake/index
- xfer 8y ago
  fpga vendors have adapted tcl as build tools for a long time.
ThisIs_MyName 8y ago
It hasn't won yet. https://bazel.build/ https://bazel.build/
- netheril96 8y ago
  bazel * does not support Windows fully. * requires users to install a large amount of dependencies (both JDK and Python 2) just to build a C project. * requires user to manually write BUILD files for all third party libraries. * has no way to discover existing libraries on the system. * no integration with IDEs (most pertinent to Windows users). Therefore bazel is not going to win over CMake any time soon. Not because it is worse, but because Google's needs are different from everyone else.

by wheels 8y ago

weberc2 8y ago

I absolutely agree. This is the number one reason I don't do any serious development in C or C++. Here are some grievances that come to mind: * Pretty much everything is a string * One giant namespace with no notion of imports * No sane dependency management; just uses whatever is laying around the system * IIRC source files have to be listed in the CMake file individually (or at least that's what I recall to be the best practice) * Everything is a one-off function. [Seriously, CMake comes with functions for Qt projects][0] and other popular libraries. * It's supposedly cross-platform, but you need to take care if you want it to generate sane, usable VS solution files. IIRC, it would create a VS project for every subdirectory or source file by default. * I forget whether CMake itself is slow as hell or if it just generates super slow Makefiles, but in either case, it is painful [0]: https://cmake.org/cmake/help/v3.0/prop_tgt/AUTOMOC.html https://cmake.org/cmake/help/v3.0/prop_tgt/AUTOMOC.html

tom_ 8y ago
Listing source files individually is what you're supposed to do, because not all build tools support globbing for files. To support this properly, cmake would need to re-run on every build to regenerate the files list... well, it's probably doable, with some work, but I expect there's just not the demand, I expect because most people are like me and would prefer to list their source files out by hand so they know where they stand. The Visual Studio projects it creates, at least for my projects, have a VS project per target. That's just how Visual Studio works. You do tend to end up with a lot of projects in one solution this way, which is something most people don't do when setting projects up by hand - but with CMake picking up the strain there's no reason not to. (It's also very convenient for running tests in the debugger. One target per test, select it as the startup project, and off you go.) As for makefiles, I haven't noticed CMake's being noticeably slower than any others I've seen, though I'm sure it's possible. They are rather larger than most Makefiles. (If you're able to switch to Ninja, that comes recommended.)
- dottrap 8y ago
  I've never had a reason to suspect CMake's Makefiles are slower than others. I've converted projects from Autotools to CMake and CMake was always miles ahead faster. I recently switched to using CMake's Ninja generator. I've been shocked at how much faster it is than Makefiles, even for tiny projects.
  - isaachier 8y ago
    This benchmark would imply that isn't usually the case: http://david.rothlis.net/ninja-benchmark/ http://david.rothlis.net/ninja-benchmark/.
    - zik 8y ago
      I just converted a large project's build system from Makefiles to meson+ninja. The ninja part is significantly faster than make was because it's keeping all the processor cores busy all the time which make doesn't do.
      - pletnes 8y ago
        alias mj=‘make -j $(nproc)’ works like a charm on all my CMake projects. Keeps the cores warm!
        jcelerier 8y ago
        Ninja does this by default but additionally has a much lower overhead on incremental rebuilds.
        cbcoutinho 8y ago
        you can also set MAKEFLAGS=" -j $(nproc)" and keep using `make` as your would normally
        pletnes 8y ago
        It’s nice to drop back to serial compilation when debugging IMHO. Sometimes one header bug causes two errors with interspersed output in parallel builds.

pornel 8y ago

The problem I have with CMake & autotools is that every project writes their build process from scratch, and everyone does things slightly differently making their project a snowflake. Certain platforms, compilers, and dependencies need special handling and workarounds, and this knowledge isn't shared and has to be repeatedly rediscovered by every project. Rust's Cargo, perhaps accidentally, has found a fantastic solution to this. The build process itself is built out of packages. I don't have to know how configure MSVC compiler, I just use an existing crate for it. I can use existing package to find and configure libpng — the work to handle its own quirky pkg-config replacement has been done once, and now every downstream project can benefit from it. Package manager in the build system may sound strange, but it's actually fantastic. It works so well that I switched my C projects to Cargo to be able to build them on Windows.

bluejekyll 8y ago
I keep considering that we might want to port Cargo to support other languages... It's better than nearly everything out there that I've ever used.
- jcelerier 8y ago
  > I keep considering that we might want to port Cargo to support other languages... It's better than nearly everything out there that I've ever used. I don't think that this would solve anything. A big problem for instance is maintainers who insist in keeping compatibility for totally obsolete stuff - see for instance zlib which clings on DOS compatibility, or Nethack which just started to use ANSI C features in the latest release ; before this they were on K&R C. As a result build sytems are terrible since they have to handle so many edge cases for obsolete compiler vendors, Watcom C & friends for instance. Rust code doesn't have this kind of legacy to handle.
  - bluejekyll 8y ago
    For C it’s not as obvious how this could be accomplished, but it would be possible. There are lots of Rust projects that embed C today, and add C flags for the LLVM. The language I was really thinking of was Java, where Cargo is far superior to maven. I’ve never had time, but what I’ve thought would be neat is to take a Cargo.toml file as input, and then generate the maven files from that, like Cargo.lock files in Rust.

TillE 8y ago

The language itself isn't great, but I don't think that's the main problem with CMake. The whole structure of the thing is like having a dump truck pour a giant pile of tools in front of you. It's all in there somewhere, but good luck figuring out which ones you need.

berkut 8y ago
Out of interest, how's this any different than other build systems like SCons, Waf? Even working out stuff like string substitutions in Make can be confusing at times, in terms of the syntax required IMO.

slavik81 8y ago

The language isn't great, but I have never spent more than a few hours trying to figure out how to do something in CMake. In other build systems, I've had to give up on some features after dozens of hours of trying. CMake is ugly, but it won because it works.

lfowles 8y ago
I'm still not convinced there's a good way in cmake to pull in and compile external libraries as dependencies. I know it can be done via a superproject method but that's a lot of boilerplate for something that should be straightforward. Everything else is simple and easy until I butt heads with that issue.
- berkut 8y ago
  In my experience, ExternalProject_Add() isn't a lot of boilerplate. You specify the source, target dir, and other stuff can be optional.
  - lfowles 8y ago
    It's been a while since I've done this kind of CMake in anger, but I recall my main gripe with ExternalProject_Add is that it can't leverage that the external project is a CMake project and I still end up hard coding paths.
    - svalorzen 8y ago
      Not sure if this can help you, but I simply use function (AddDependency name) add_subdirectory(${PROJECT_SOURCE_DIR}/deps/${name}) include_directories(${PROJECT_SOURCE_DIR}/deps/${name}/include) endfunction (AddDependency) And then use git submodule to clone all the dependencies I need in the deps folder. Everything then works automagically (assuming that the dependency is built through CMake).
- isaachier 8y ago
  Check out https://github.com/ruslo/hunter https://github.com/ruslo/hunter for a fantastic CMake package manager built to solve this issue.

bch 8y ago

What boggles my mind is that it was conceived on a project (medical imaging, iirc) where they were using Tcl as an embedded language, decided to create a new build system that needed an embedded language and... decided to write one from scratch? I would have love, love, LOVED to see Tcl in that space.

jzwinck 8y ago
They thought if they used Tcl, CMake would not have enjoyed widespread adoption: http://www.aosabook.org/en/cmake.html http://www.aosabook.org/en/cmake.html To me, the CMake language is the only part that keeps me on the lookout for a CMake replacement.
gaius 8y ago
I would have love, love, LOVED to see Tcl in that space. 100% agree, a Tcl based build system would be a dream come true. I wonder why they thought it would not enjoy widespread adoption. Plenty of Tcl-based systems did, after all, and it's only because of fashion now that people aren't still using it.
- bch 8y ago
  There is smake[0], which I use a lot, and lots of room to grow with (I.e.: dig in and figure out idioms), but Tcl/cmake could have been very interesting. [0] http://chiselapp.com/user/Setok/repository/smake/index http://chiselapp.com/user/Setok/repository/smake/index
xfer 8y ago
fpga vendors have adapted tcl as build tools for a long time.

ThisIs_MyName 8y ago

It hasn't won yet. https://bazel.build/ https://bazel.build/

netheril96 8y ago
bazel * does not support Windows fully. * requires users to install a large amount of dependencies (both JDK and Python 2) just to build a C project. * requires user to manually write BUILD files for all third party libraries. * has no way to discover existing libraries on the system. * no integration with IDEs (most pertinent to Windows users). Therefore bazel is not going to win over CMake any time soon. Not because it is worse, but because Google's needs are different from everyone else.