6 ms·

I did my fair share of setting up C and C++ builds in the past and I can tell you: The difference between CMake and Autoconf is marginal, while CMake is of cour

I did my fair share of setting up C and C++ builds in the past and I can tell you: The difference between CMake and Autoconf is marginal, while CMake is of course a bit more versatile in terms of target build-systems, and of course its DSL is not as obscure as autotools toolchain, its no meaningful difference. What Bazel (or Buck) bring to the table is slightly different, its better control of inter-module dependencies and external dependencies. In a way they are not only build tools but opinionated and effective 'linkers', bundling together your applications and libraries in a way that it is hard to mess up and very reproducible. The other option would be the nix/guix route, which I think might be better-suited for the open-source model but require you to adapt at least the package managers.

Teknoman117 6y ago
The meaningful difference for me is that I work in a place where most of the developers love their IDEs. CMake is literally the only cross platform build system with first class IDE support on both Windows and Linux. If you use VS Code on macOS, you get it there as well.
- jhasse 6y ago
  > If you use VS Code on macOS, you get it there as well. CMake can generate Xcode projects.
  - Teknoman117 6y ago
    Right, what I meant by developers who love their IDEs is that they complain if they see a console. They just want to open an IDE and click "open folder" or "open project", so not having to use an intermediate IDE project generator is a massive boon.
- ajconway 6y ago
  CMake does very good when you have a C/C++ project, but it very poorly suited for cross-language dependencies. Blaze-like build systems, on the other hand, were built specifically for that.
- JamesSwift 6y ago
  After digging into Bazel a bit recently, I really hope they invest significant energy into the IDE story next. That is a huge, gaping hole that is being not-really solved in all the language/IDE ecosystems and is a _massive_ roadblock to adoption. IDE integration would remove 90% of my hesitation to push it at my company.
  - vlovich123 6y ago
    It’s not much work. Internally at Google they have Idea integration. The challenge for open sourcing it may be that the plugin is also responsible for Google3 integration if I recall correctly.
    - JamesSwift 6y ago
      "not much work" is absolutely not the feeling I have about it based on some conference talks about the topic (e.g. the various xcode talks, or the Wix talks on intelliJ), and my own thought experiments on getting it tied into Visual Studio / Visual Studio for Mac. I think the Bazel team introduced Aspects and punted the rest for a later date. Now they hope each language/IDE community will take that infrastructure and build out the rest of the ecosystem. I think its too important of a piece of the puzzle to leave to the community.
  - Teknoman117 6y ago
    I really like Bazel as well. As you said, cross language dependency management in CMake is hilariously annoying. However, I'm at practically a C++ only shop so it rarely comes up. Where I am we were using CMake 2 for our build system for a long time and it got into bad shape. When we made the decision to rewrite the build system (across a few dozen subprojects), we looked at a few - Meson, Bazel, CMake, etc. CMake was hard to argue against because of the recent work (last few years) by Microsoft to support CMake projects directly (File -> Open Folder). We wanted to try to get away from maintaining separate IDE projects for every platform for every project.
outsomnia 6y ago
Well, one "meaningful difference" is I can find devs who have experience with cmake...
- EdSchouten 6y ago
  You have to start somewhere, right? The same thing was said about things like Kubernetes a couple of years ago. Look at where we are now.
  - bluGill 6y ago
    Autoconf has been around for years, cmake for much less, yet cmake was able to become the major build system for C++ and get everywhere. I don't think autoconf has a future - even when it was "the only choice" everyone avoided it if they could. Cmake took over and became the thing everyone knew. Now if you (like the article) proposing something else you might have a chance. However autoconf has lost.
    - klodolph 6y ago
      Autoconf "lost" in the sense that it solved the problems that it needed to solve and is no longer needed.
      - bregma 6y ago
        Autoconf solves the problem of easily porting software to different systems because autodiscovery is its default modus operandi. Now that we live in a post-innovation world, there is no need to port software: it's either Linux, Mac OS, or Windows. Except, of course, there is still a lot of innovation going on, and there's a lot of porting and cross-building that happens outside the the web domain, and a heck of a lot of things that are none of the big three development hosts. CMake is starting to converge towards what the autotools have provided for some decades now, but it's not there yet. When it comes down to it, the only real difference is different domain-specific languages and that just results in tribalism.
bluGill 6y ago
The meaningful difference for me is I cross compile everything. Every cmake project I've worked with just works. As in it only takes a couple hours to get it packaged for my custom (stupid...) package system I have to use, almost all of that boilerplate work. Only 1 in 50 autoconf project I've worked with actually works - in theory autoconf supports this case well, but in practice there is always something broken and so I know I'll spend a couple weeks (full time) getting it packaged.

Teknoman117 6y ago

The meaningful difference for me is that I work in a place where most of the developers love their IDEs. CMake is literally the only cross platform build system with first class IDE support on both Windows and Linux. If you use VS Code on macOS, you get it there as well.

jhasse 6y ago
> If you use VS Code on macOS, you get it there as well. CMake can generate Xcode projects.
- Teknoman117 6y ago
  Right, what I meant by developers who love their IDEs is that they complain if they see a console. They just want to open an IDE and click "open folder" or "open project", so not having to use an intermediate IDE project generator is a massive boon.
ajconway 6y ago
CMake does very good when you have a C/C++ project, but it very poorly suited for cross-language dependencies. Blaze-like build systems, on the other hand, were built specifically for that.
JamesSwift 6y ago
After digging into Bazel a bit recently, I really hope they invest significant energy into the IDE story next. That is a huge, gaping hole that is being not-really solved in all the language/IDE ecosystems and is a _massive_ roadblock to adoption. IDE integration would remove 90% of my hesitation to push it at my company.
- vlovich123 6y ago
  It’s not much work. Internally at Google they have Idea integration. The challenge for open sourcing it may be that the plugin is also responsible for Google3 integration if I recall correctly.
  - JamesSwift 6y ago
    "not much work" is absolutely not the feeling I have about it based on some conference talks about the topic (e.g. the various xcode talks, or the Wix talks on intelliJ), and my own thought experiments on getting it tied into Visual Studio / Visual Studio for Mac. I think the Bazel team introduced Aspects and punted the rest for a later date. Now they hope each language/IDE community will take that infrastructure and build out the rest of the ecosystem. I think its too important of a piece of the puzzle to leave to the community.
- Teknoman117 6y ago
  I really like Bazel as well. As you said, cross language dependency management in CMake is hilariously annoying. However, I'm at practically a C++ only shop so it rarely comes up. Where I am we were using CMake 2 for our build system for a long time and it got into bad shape. When we made the decision to rewrite the build system (across a few dozen subprojects), we looked at a few - Meson, Bazel, CMake, etc. CMake was hard to argue against because of the recent work (last few years) by Microsoft to support CMake projects directly (File -> Open Folder). We wanted to try to get away from maintaining separate IDE projects for every platform for every project.

outsomnia 6y ago

Well, one "meaningful difference" is I can find devs who have experience with cmake...

EdSchouten 6y ago
You have to start somewhere, right? The same thing was said about things like Kubernetes a couple of years ago. Look at where we are now.
- bluGill 6y ago
  Autoconf has been around for years, cmake for much less, yet cmake was able to become the major build system for C++ and get everywhere. I don't think autoconf has a future - even when it was "the only choice" everyone avoided it if they could. Cmake took over and became the thing everyone knew. Now if you (like the article) proposing something else you might have a chance. However autoconf has lost.
  - klodolph 6y ago
    Autoconf "lost" in the sense that it solved the problems that it needed to solve and is no longer needed.
    - bregma 6y ago
      Autoconf solves the problem of easily porting software to different systems because autodiscovery is its default modus operandi. Now that we live in a post-innovation world, there is no need to port software: it's either Linux, Mac OS, or Windows. Except, of course, there is still a lot of innovation going on, and there's a lot of porting and cross-building that happens outside the the web domain, and a heck of a lot of things that are none of the big three development hosts. CMake is starting to converge towards what the autotools have provided for some decades now, but it's not there yet. When it comes down to it, the only real difference is different domain-specific languages and that just results in tribalism.

bluGill 6y ago

The meaningful difference for me is I cross compile everything. Every cmake project I've worked with just works. As in it only takes a couple hours to get it packaged for my custom (stupid...) package system I have to use, almost all of that boilerplate work. Only 1 in 50 autoconf project I've worked with actually works - in theory autoconf supports this case well, but in practice there is always something broken and so I know I'll spend a couple weeks (full time) getting it packaged.