1. 13
  1.  

  2. 15

    I’ve never bothered with qmake, but I’ve had some awful experiences with CMake. To be honest, whenever I see a project that requires CMake to build, I often just close the tab rather than even trying to build it, because CMake builds rarely - if ever - succeed.

    I agree with every point the article makes. For CMake being such a complex and “full-featured” build tool, it’s broken in pretty fundamental ways. Also the suckless guys don’t like it, and as some of the best C developers I’ve seen, that’s a pretty good reason to stay away from CMake.

    1. 12

      I’ve had the same experience. I’ve found that the simpler the build system, the more likely I’ll build it successfully. e.g. almost every project I’ve found that just uses plain old Makefiles I can figure out how to build. Even if it errors, it’s easy to see why/how and fix it.

      1. 5

        Exactly. Makefiles are simple and transparent (and somehow manage to be more standardized CMake). I know that make && make install will work with the vast majority of Makefiles, while the CMake command seems to vary for each project.

        1. 6

          On the contrary. I know that anything with a Makefile with fail spectacularly. Major cause: no configure step.

          Autotools is painfully slow, complicated and messy but generally works.

          I don’t see many CMake projects around but everything I have tried has worked I think.

          1. 3

            Is it possible that projects that use Make tend to be easier to build because they are usually smaller and less complicated than a project that needs the functionality of something like CMake or Autotools?

            1. 7

              OpenBSD is built without the use of CMake or Autotools. Just BSD make.

              1. 3

                OpenBSD would normally be built in an OpenBSD environment I would suspect, and has a configuration file.

                1. 4

                  I think you’re getting at it depending on one environment to build one environment. Whereas the other tools are smoothing over issues involving many environments.

          2. 3

            That’s the opposite of my experience back when I built software on interix, or when I cross-compiled for Angstrom. Any “complex” standardised build system - be that autotools, cmake, scons or something else - worked fine. Projects that used “simple” makefiles were impossible to build.

          3. 5

            I’ve maintained code both using cmake and plain make. Cmake is awful, and for a Unix project, I’d pick make any day. Cmake is also within epsilon of being your only option if you care about good Windows support, so I don’t see it going away in the near to medium term future.

            1. 6

              What? When I see a CMake project I can typically build it like this:

              cmake -G "Unix Makefiles"
              make
              

              On some projects with non-packaged dependencies, this does not work. But the same problem is true for Autotools projects that require the paths of certain dependencies to be specified during the configure step.

            2. 7

              I spend a lot of time on Windows, and I am usually happy when I spot a CMakeLists.txt, because then there is a chance it will build with MSVC and plain mingw-w64. Otherwise you usually have to try your luck with some project file contributed years ago and never updated, or resort to Cygwin.

              Don’t get me wrong, CMake is in some ways an awful language. Writing CMake scripts that are backwards compatible with the versions in stable distributions is a pain. Or how about the way lists are semicolon-separated strings, except if one of the strings happen to contain a stray square bracket to trip you up.

              But I think it is the best option at the moment for making things build on all of Windows (with MSVC), OS X, and Linux.

              1. 10

                Say what you want about CMakes user experience, but there is a reason that tools like cmake or the autotools were created in the first place.

                plain Makefiles are great if you have a small project. With the growth of your project, your hand-rolled Makefile will just explode in complexity. Also, you will reinvent the wheel multiple times, and probably miss a few conventions in Makefile writing. The makefiles of your projects will all differ in subtle ways. This might still work out for you, if you wrote those makefiles yourself and know their quirks (they are optimized for your personal workflow after all).

                But chances are high, that when taking over maintenance of a random C or C++ project with a hand-rolled Makefile, you stumble over weird stuff that will keep you busy and debugging for days. Like a make clean not cleaning targets but only intermediates or some phony make target deleting source files.

                Projects I admire use plain Makefiles, but they are often really written by experienced demi-gods (luajit). With all its weaknesses, cmake is the best choice probably, until a better build tool emerges, and it probably even is good enough that this isn’t happening soon (the clang project might be the only ones I could see writing one - looking at their track record of innovating C/C++ tooling with clang-format and the likes, haven’t actually researched if they are already up to it).

                Autotools are okayish, if you can put up with tons of boilerplate files and a very bazar-style combination of tools.

                Scons is rather a replacement for plain-make in the sense that it tends to accumulate a lot of boilerplate and hand-rolled logic. Fortunately since it is a Python DSL, at least you don’t need to spend hours searching for documentation on different wildcard flavours, shorthands and other historically-accumulated features of Gnu make.

                1. 4

                  I’m not sure how relevant the pkg-config and install complaints are these days for CMake (they seemed to work in the projects I’ve used recently), but I’ll agree with the documentation gripe. It’s documentation is extensive, yet if you start to read it, you don’t come away with much. You’re pretty much forced to learn its programming language though the book and via “man stackoverflow” until you get an idea as to what is going on.

                  Really, I haven’t come across a build system that isn’t hell to work with or debug when a project gets large. It takes a lot of discipline to keep it in good shape. That said, I prefer well organized makefiles to well organized anything else. (But if you need Windows support, CMake is a better choice.)

                  1. 3

                    I have used CMake about 10 years ago. I remember being very confused at first but then after learning some basics very happy.

                    It was great for allowing a Visual Studio setup and at the same time providing a convenient way to build the project on the CLI. Cross-plattform AND cross-build tool. And much faster configure step than auto-tools.

                    1. 2

                      Wow cmake is taking a lot of heat here. Admittedly I’m not doing anything particularly interesting with it, but CMake has served just fine as the build system for one of my toy projects - dirt - dirt/CMakeLists.txt. Admittedly I mostly interact with it via a bunch of bash - dirt/dirt and I’m only targeting a single platform but compared to figuring out the pattern language to use core Make or figuring out Auto-tools which…. didn’t seem particularly user friendly when I looked at it briefly.