5 ms·

CMake is a big improvement, but it's a shame they didn't opt for Buck or Bazel. These two build systems are as much an improvement over the previous generation

CMake is a big improvement, but it's a shame they didn't opt for Buck or Bazel. These two build systems are as much an improvement over the previous generation as autoconf and GNU Make were improvements over random ad-hoc configure scripts. Both take pains to ensure that builds are fully hermetic and fully reproducible, support rich introspection, and run very, very fast.

aristidb 9y ago
True, but Cmake has a lot of users already familiar with it and who have it pre-installed. So I applaud this change to use Cmake!
- ungzd 9y ago
  It looks like few people are familiar with CMake, others are just copy-pasting snippets of configuration code from googled results. And noone knows how to do it right. The same is with Autotools.
  - SXX 9y ago
    Even if you look at Kitware own products they full of quite outdated and ugly code. I think it's because amount of code and platform-specific hacks in CMake / CPack / CTest is just too hard to maintain and many things will break hard while there was no changes in them for years. Also copy-pasting sometimes work better simply because very few developers actually able to check how their own configuration work across multiple platforms and endless number of Linux distributions. It's might look easy to make your own configuration, but once you try to at least cover Windows, Mac and Deb-based Linux it's take weeks to debug everything. Instead you can copy-paste someone else module, change few lines and it's will already cover everything you need. EDIT: typo: on -> once
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
petters 9y ago
But Cmake has support for IDEs like Visual Studio. That is a huge benefit compared to Bazel.
netheril96 9y ago
Neither Buck nor Bazel have mature support for Windows. And I very much dislike them for the enormous amount of dependency.
- oneplane 9y ago
  But unless you are confined to Windows, that doesn't really matter, does it? Most code for Windows seems to be written using Microsoft's own tools as far as I know, which makes both the people asking for FOSS tools and the people that make FOSS tools to begin with less likely to target Windows.
  - tonyarkles 9y ago
    The beauty of CMake, for me, is that it can generate both Makefiles and VS2015 files. An example that I've posted here before about was a userland USB driver backed by libusb. I wrote it in idiomatic C++11 (or C++14, don't remember exactly), and amazingly I was able to generate a .so, a .dyld, and a .dll from the same source code, without needing a single #ifdef. Built using gcc on Linux, clang on OSX, and VS2015 on Windows. CMake would output Makefiles on the first two, and a VS solution file on Windows that I could build. I'm still amazed by it a couple years later.
  - mwfunk 9y ago
    That's a pretty ginormous "but unless...". It would not surprise me if more people are building and using Boost than all other platforms put together. I haven't done any Windows development in 10+ years, but it's not like everyone else stopped when I did.
  - vinkelhake 9y ago
    We're in the context of Boost here and it has great support for Windows. Switching to a build system that doesn't have mature support for Windows is simply a non-starter for the Boost project. That a lot of FOSS projects (understandably) have poor support for Windows doesn't mean that all of them do. It also doesn't mean there isn't demand for FOSS projects on that platform.
  - 9y ago
0xFFC 9y ago
I completely disagree. Other companies do provide excellent support for CMake right now. Take for example android new cmake toolchain support for compiling for android. Compiling your project for Android is as easy as adding a command line parameter. Neither Buck and Bazel are nowhere near as Cmake. As someone who works with C++ and cross compiles code to arm. I really appreciate and enjoyed with recent trends in porting codes to cmake build(prebuild?) system .
ungzd 9y ago
Buck and Bazel are definitely far better designed than these scary piles of macros like CMake and Autotools, but far from being ready for the same use cases. These new tools are designed for Google and Facebook's specific use cases: building binaries to run on their own servers, or mobile apps, from sources in monorepos (with dependencies copied to repo![1]). I think even building packages for Linux distros is hard with these systems and cross compilation is barely documented too (however seems that it is supported, even for Windows). There are no discovery of libraries installed in system and features of system (killer feature of autotools). [1] https://buckbuild.com/command/fetch.html https://buckbuild.com/command/fetch.html
corndoge 9y ago
Or meson, which gnome and systemd now support, among other big projects.
- moosingin3space 9y ago
  While bazel and buck look great for building Google/Facebook-sized codebases, meson looks great for what most of our projects are.
JoshTriplett 9y ago
Personally, I'd much rather see Meson than either one. But CMake is still a solid, mature choice here.
- lomnakkus 9y ago
  One obvious issue with Meson is that it's not really available as a (statically-compiled, if you want) binary. I was an early adopter (years and years ago) of Scons, but the Python dependency turned out to be an absolute disaster, purely in terms of infrastructure (especially that everybody had to have a lot of "things" installed). While CMake isn't exactly great, a) it is reasonably understandable, and b) the boost build system was essentially a single-project-build system, and c) it's a huge improvement over autoconf, and d) it doesn't need a lot of infrastructure aside from what ships with it (to contrast with 'interpreted' build systems).
yorwba 9y ago
My only experience with Bazel was building TensorFlow. I can't say that the builds were fully reproducible or very fast. That TensorFlow is a big project excuses the speed (most of the time was probably spent actually compiling), but I had to rebuild three times until setting the flag for GPU support had the desired effect. So whatever magic was supposed to deliver reproducibility was not working. Add to that issues with some Bazel processes hogging resources in the background and I was wishing for some good old makefiles.

aristidb 9y ago

True, but Cmake has a lot of users already familiar with it and who have it pre-installed. So I applaud this change to use Cmake!

ungzd 9y ago
It looks like few people are familiar with CMake, others are just copy-pasting snippets of configuration code from googled results. And noone knows how to do it right. The same is with Autotools.
- SXX 9y ago
  Even if you look at Kitware own products they full of quite outdated and ugly code. I think it's because amount of code and platform-specific hacks in CMake / CPack / CTest is just too hard to maintain and many things will break hard while there was no changes in them for years. Also copy-pasting sometimes work better simply because very few developers actually able to check how their own configuration work across multiple platforms and endless number of Linux distributions. It's might look easy to make your own configuration, but once you try to at least cover Windows, Mac and Deb-based Linux it's take weeks to debug everything. Instead you can copy-paste someone else module, change few lines and it's will already cover everything you need. EDIT: typo: on -> once

deleted 9y ago

[deleted]

deleted 9y ago

[deleted]

petters 9y ago

But Cmake has support for IDEs like Visual Studio. That is a huge benefit compared to Bazel.

netheril96 9y ago

Neither Buck nor Bazel have mature support for Windows. And I very much dislike them for the enormous amount of dependency.

oneplane 9y ago
But unless you are confined to Windows, that doesn't really matter, does it? Most code for Windows seems to be written using Microsoft's own tools as far as I know, which makes both the people asking for FOSS tools and the people that make FOSS tools to begin with less likely to target Windows.
- tonyarkles 9y ago
  The beauty of CMake, for me, is that it can generate both Makefiles and VS2015 files. An example that I've posted here before about was a userland USB driver backed by libusb. I wrote it in idiomatic C++11 (or C++14, don't remember exactly), and amazingly I was able to generate a .so, a .dyld, and a .dll from the same source code, without needing a single #ifdef. Built using gcc on Linux, clang on OSX, and VS2015 on Windows. CMake would output Makefiles on the first two, and a VS solution file on Windows that I could build. I'm still amazed by it a couple years later.
- mwfunk 9y ago
  That's a pretty ginormous "but unless...". It would not surprise me if more people are building and using Boost than all other platforms put together. I haven't done any Windows development in 10+ years, but it's not like everyone else stopped when I did.
- vinkelhake 9y ago
  We're in the context of Boost here and it has great support for Windows. Switching to a build system that doesn't have mature support for Windows is simply a non-starter for the Boost project. That a lot of FOSS projects (understandably) have poor support for Windows doesn't mean that all of them do. It also doesn't mean there isn't demand for FOSS projects on that platform.
- 9y ago

0xFFC 9y ago

I completely disagree. Other companies do provide excellent support for CMake right now. Take for example android new cmake toolchain support for compiling for android. Compiling your project for Android is as easy as adding a command line parameter. Neither Buck and Bazel are nowhere near as Cmake. As someone who works with C++ and cross compiles code to arm. I really appreciate and enjoyed with recent trends in porting codes to cmake build(prebuild?) system .

ungzd 9y ago

Buck and Bazel are definitely far better designed than these scary piles of macros like CMake and Autotools, but far from being ready for the same use cases. These new tools are designed for Google and Facebook's specific use cases: building binaries to run on their own servers, or mobile apps, from sources in monorepos (with dependencies copied to repo![1]). I think even building packages for Linux distros is hard with these systems and cross compilation is barely documented too (however seems that it is supported, even for Windows). There are no discovery of libraries installed in system and features of system (killer feature of autotools). [1] https://buckbuild.com/command/fetch.html https://buckbuild.com/command/fetch.html

corndoge 9y ago

Or meson, which gnome and systemd now support, among other big projects.

moosingin3space 9y ago
While bazel and buck look great for building Google/Facebook-sized codebases, meson looks great for what most of our projects are.

JoshTriplett 9y ago

Personally, I'd much rather see Meson than either one. But CMake is still a solid, mature choice here.

lomnakkus 9y ago
One obvious issue with Meson is that it's not really available as a (statically-compiled, if you want) binary. I was an early adopter (years and years ago) of Scons, but the Python dependency turned out to be an absolute disaster, purely in terms of infrastructure (especially that everybody had to have a lot of "things" installed). While CMake isn't exactly great, a) it is reasonably understandable, and b) the boost build system was essentially a single-project-build system, and c) it's a huge improvement over autoconf, and d) it doesn't need a lot of infrastructure aside from what ships with it (to contrast with 'interpreted' build systems).

yorwba 9y ago

My only experience with Bazel was building TensorFlow. I can't say that the builds were fully reproducible or very fast. That TensorFlow is a big project excuses the speed (most of the time was probably spent actually compiling), but I had to rebuild three times until setting the flag for GPU support had the desired effect. So whatever magic was supposed to deliver reproducibility was not working. Add to that issues with some Bazel processes hogging resources in the background and I was wishing for some good old makefiles.