5 ms·

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 n

by 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.
        tom_ 8y ago
        Ninja serializes each tool's output. (I imagine it buffers the output internally. With a moment's thought you can imagine situations specifically engineered to cause more problems than this solves, but I've been using Ninja for a couple of years now and I've yet to see that happen.)
        pletnes 8y ago
        make -O does the same. In fact, it can serialize a whole target, at the cost of buffering that output.
        tom_ 8y ago
        Awesome ;) - thanks for this note. I've been using the same no-dependency no-cygwin Windows build of 3.80 for about ten years, and OS X comes with 3.81, so my GNU Make skills never got any further than that. But this has prompted me to track down a similar Windows build of GNU Make 4.21, so all I need to do now is figure out how to get one set up on OS X... This won't get me to switch away from Ninja when using CMake, but I write my own -j-friendly makefiles sometimes, so this will come in handy.
  - deleted 8y ago
    [deleted]
weberc2 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. Sincerely, have you spent much time with other languages? Very few require so much from the user. It just now occurred to me that CMake isn’t so much of a build tool as it is a homegrown framework for making homegrown build tools. I don’t mean that to be insulting; I think it explains a lot of the differences of opinion about CMake; if you’re expecting a build tool like Cargo, you’ll be sorely disappointed, but if you’d like to make a one-off build tool for your project then maybe it’s not so bad? That said, I probably spent 10-15 percent of my time managing CMake, and I wasn’t doing anything particularly novel; just trying to wire in some new library (like Qt back when everyone had a recipe that worked for their project but no one else’s) or testing framework (I remember GTest being particularly painful) or make builds reproducible or fetch libraries from a repository. Stuff that people in other languages get for free these days. I guess I just want nice things for the C/C++ communities as well.
- therealjumbo 8y ago
  I think alot of C/C++ devs have spent time in other languages, particularly python. And they generally have their own pathological problems, like pip. Cargo is probably one of very few build tools that does almost everything correctly. So if you use almost any other build tools you're trading one set of problems for another. Granted, the issues aren't as hard to understand as C++ ABI incompatibilities but they are more or less just as hard for the tool to auto fix. I think the overalls point is that the tool should support that language and so on. I'm sure everyone has their own horror cmake or autotools debugging story, but I think we are all very interested in a better way to solve the problem. If you're point is, well you should just use a different language, you probably don't know the requirements well enough.
  - weberc2 8y ago
    Yeah, I own the build system for our code which is all in Python. Pip is the package manager, not the build system, but your greater point stands: Python’s build tooling isn’t great (although pipenv is a significant improvement). While few tools match up to Cargo, CMake is still uniquely unpleasant in my view. Most others aren’t fully imperative programming languages and at least have some ability or convention for locating sources. Many serve as a package manager or they dovetail nicely with a package manager. Go’s package manager story is a work in progress but I still prefer it to CMake (no contest). My point isn’t that you should use a different language, my point is that CMake doesn’t compare to the tooling in other languages and there isn’t a compelling reason—it’s success is a historical accident, and I hope the community arrives at something better. I’m of the impression that there are other tools that are interested in solving this problem and I wish them luck.

by tom_ 8y ago

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.
        tom_ 8y ago
        Ninja serializes each tool's output. (I imagine it buffers the output internally. With a moment's thought you can imagine situations specifically engineered to cause more problems than this solves, but I've been using Ninja for a couple of years now and I've yet to see that happen.)
        pletnes 8y ago
        make -O does the same. In fact, it can serialize a whole target, at the cost of buffering that output.
        tom_ 8y ago
        Awesome ;) - thanks for this note. I've been using the same no-dependency no-cygwin Windows build of 3.80 for about ten years, and OS X comes with 3.81, so my GNU Make skills never got any further than that. But this has prompted me to track down a similar Windows build of GNU Make 4.21, so all I need to do now is figure out how to get one set up on OS X... This won't get me to switch away from Ninja when using CMake, but I write my own -j-friendly makefiles sometimes, so this will come in handy.
- deleted 8y ago
  [deleted]

weberc2 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. Sincerely, have you spent much time with other languages? Very few require so much from the user. It just now occurred to me that CMake isn’t so much of a build tool as it is a homegrown framework for making homegrown build tools. I don’t mean that to be insulting; I think it explains a lot of the differences of opinion about CMake; if you’re expecting a build tool like Cargo, you’ll be sorely disappointed, but if you’d like to make a one-off build tool for your project then maybe it’s not so bad? That said, I probably spent 10-15 percent of my time managing CMake, and I wasn’t doing anything particularly novel; just trying to wire in some new library (like Qt back when everyone had a recipe that worked for their project but no one else’s) or testing framework (I remember GTest being particularly painful) or make builds reproducible or fetch libraries from a repository. Stuff that people in other languages get for free these days. I guess I just want nice things for the C/C++ communities as well.

therealjumbo 8y ago
I think alot of C/C++ devs have spent time in other languages, particularly python. And they generally have their own pathological problems, like pip. Cargo is probably one of very few build tools that does almost everything correctly. So if you use almost any other build tools you're trading one set of problems for another. Granted, the issues aren't as hard to understand as C++ ABI incompatibilities but they are more or less just as hard for the tool to auto fix. I think the overalls point is that the tool should support that language and so on. I'm sure everyone has their own horror cmake or autotools debugging story, but I think we are all very interested in a better way to solve the problem. If you're point is, well you should just use a different language, you probably don't know the requirements well enough.
- weberc2 8y ago
  Yeah, I own the build system for our code which is all in Python. Pip is the package manager, not the build system, but your greater point stands: Python’s build tooling isn’t great (although pipenv is a significant improvement). While few tools match up to Cargo, CMake is still uniquely unpleasant in my view. Most others aren’t fully imperative programming languages and at least have some ability or convention for locating sources. Many serve as a package manager or they dovetail nicely with a package manager. Go’s package manager story is a work in progress but I still prefer it to CMake (no contest). My point isn’t that you should use a different language, my point is that CMake doesn’t compare to the tooling in other languages and there isn’t a compelling reason—it’s success is a historical accident, and I hope the community arrives at something better. I’m of the impression that there are other tools that are interested in solving this problem and I wish them luck.