4 ms·

For better or worse though, CMake has won! Many IDE's including Visual Studio can directly work with CMake files. In addition, even Google which is famous for d

For better or worse though, CMake has won! Many IDE's including Visual Studio can directly work with CMake files. In addition, even Google which is famous for doing things their own way, has now added official, first-class CMake support to their open source C++ library Abseil https://abseil.io/blog/20190402-cmake-support https://abseil.io/blog/20190402-cmake-support If you are writing an open source C++ library, even if you support some other C++ build system, chances are you will also have CMake support as well. While I have no doubt, xmake is easier to use than CMake (just having Lua over CMake's abomination of a language is a great improvement), the fact that so many libraries and tools already support CMake is going to make adoption an uphill battle.

kevin_thibedeau 8y ago
Now we just need a better DSL that can generate Cmake files.
- usrnm 8y ago
  And CMake itself started as a simple DSL for generating Makefiles. We've gone full circle
  - geezerjay 8y ago
    CMake is still a DSL for generating makefiles.
    - YayamiOmate 8y ago
      Yea, but what it's not is simple. Imho dealing with dependencies and making project build in one shot is hard in cmake. Maybe I did things wrong though.
      - geezerjay 8y ago
        > Yea, but what it's not is simple. That really depends on what you're trying to do. Cmake's happy path for building an executable that depends only on libraries that already support cmake is very straight-forward.
geezerjay 8y ago
Cmake won against the incumbent, which was autotools. Still it's still far from being an enjoyable tool, whose experience is made even worse by its god-awful docs.
- de_watcher 8y ago
  I find the docs to be fine...
- shstalwart 8y ago
  Personally, I vastly prefer autotools, both as a user and developer. When I got to the point I needed some kind of build system, I found autotools much easier to learn than cmake. As user, I find the experience with autotools to be much nicer as well. For whatever reason, the interface just seems more intuitive. I mean, ./configure --help will tell you basically all you need to know. An underappreciated bonus is that you don't have to install more stuff just to __build__ some program you might not even want. I've run into more than one project that required a specific version of cmake, which as luck would have it, was not the version packaged with my distro. This leaves you either building another cmake first or finding a tool/library that isn't so persnickety. Given the choice between trying a project that uses CMake or or autools, I'll choose the autotools based project every time.
  - jcelerier 8y ago
    > An underappreciated bonus is that you don't have to install more stuff just to __build__ some program you might not even want. sorry what ? I remember hours in my younger years searching which Debian package provided autowhateverflavoroftheday.sh so that I could build $random internet project
    - jlokier 8y ago
      > > An underappreciated bonus is that you don't have to install more stuff just to __build__ some program you might not even want. > sorry what ? I remember hours in my younger years searching which Debian package provided autowhateverflavoroftheday.sh so that I could build $random internet project The whole point of Autotools is that distributed source packages can be built by themselves, without requiring any part of Autotools to be installed. They build even on obscure systems that don't have any working version of Autotools. If you have to install autoanything to build a random project that uses Autotools, either you are doing something wrong, or the project is using Autotools wrong, or maybe the Debian package is using Autotools wrong. That said, I know what you mean. I've had to seek out a number of different versions of Autotools just to get some things to build. But that is because a lot of projects and/or distro packaging blatantly uses Autotools differently than it's was designed to be used. I don't think Autotools should be blamed for this.
yoz-y 8y ago
I quite like CMake, I find it to be the least bad of the bunch. With recent additions I'd say that the only problem is that many packages still need to pull a CMake module from somewhere to be found because they do not offer pkg-config files.

kevin_thibedeau 8y ago

Now we just need a better DSL that can generate Cmake files.

usrnm 8y ago
And CMake itself started as a simple DSL for generating Makefiles. We've gone full circle
- geezerjay 8y ago
  CMake is still a DSL for generating makefiles.
  - YayamiOmate 8y ago
    Yea, but what it's not is simple. Imho dealing with dependencies and making project build in one shot is hard in cmake. Maybe I did things wrong though.
    - geezerjay 8y ago
      > Yea, but what it's not is simple. That really depends on what you're trying to do. Cmake's happy path for building an executable that depends only on libraries that already support cmake is very straight-forward.

geezerjay 8y ago

Cmake won against the incumbent, which was autotools. Still it's still far from being an enjoyable tool, whose experience is made even worse by its god-awful docs.

de_watcher 8y ago
I find the docs to be fine...
shstalwart 8y ago
Personally, I vastly prefer autotools, both as a user and developer. When I got to the point I needed some kind of build system, I found autotools much easier to learn than cmake. As user, I find the experience with autotools to be much nicer as well. For whatever reason, the interface just seems more intuitive. I mean, ./configure --help will tell you basically all you need to know. An underappreciated bonus is that you don't have to install more stuff just to __build__ some program you might not even want. I've run into more than one project that required a specific version of cmake, which as luck would have it, was not the version packaged with my distro. This leaves you either building another cmake first or finding a tool/library that isn't so persnickety. Given the choice between trying a project that uses CMake or or autools, I'll choose the autotools based project every time.
- jcelerier 8y ago
  > An underappreciated bonus is that you don't have to install more stuff just to __build__ some program you might not even want. sorry what ? I remember hours in my younger years searching which Debian package provided autowhateverflavoroftheday.sh so that I could build $random internet project
  - jlokier 8y ago
    > > An underappreciated bonus is that you don't have to install more stuff just to __build__ some program you might not even want. > sorry what ? I remember hours in my younger years searching which Debian package provided autowhateverflavoroftheday.sh so that I could build $random internet project The whole point of Autotools is that distributed source packages can be built by themselves, without requiring any part of Autotools to be installed. They build even on obscure systems that don't have any working version of Autotools. If you have to install autoanything to build a random project that uses Autotools, either you are doing something wrong, or the project is using Autotools wrong, or maybe the Debian package is using Autotools wrong. That said, I know what you mean. I've had to seek out a number of different versions of Autotools just to get some things to build. But that is because a lot of projects and/or distro packaging blatantly uses Autotools differently than it's was designed to be used. I don't think Autotools should be blamed for this.

yoz-y 8y ago

I quite like CMake, I find it to be the least bad of the bunch. With recent additions I'd say that the only problem is that many packages still need to pull a CMake module from somewhere to be found because they do not offer pkg-config files.