1. 18
  1.  

  2. 31

    It’s not the 10-line-Makefiles I’m afraid of. I’m afraid of 6000 line self-modifying Makefiles that appear to be autogenerated, while in reality they’re maintained by one single guy working in the company for 20 years, who is at the same time the only person that can understand the build system. I’m afraid of custom features like: automatic file discovery but only from specific directories, automatic dependency tracking but only for some class of files, template engine (like m4, but implemented using Makefile+sed), and requires specific version of the system, and specific version of SDK, plus clean checkout of the project requires creating special files in special places in special order, plus compilation of specific targets needs to be done from special directories (and it’s an in-source build system), plus requires thirdparty tools in specific versions installed in specific places.

    1. 20

      Or, more concisely, “software”.

      1. 7

        Yes, but also the Makefiles generated by autoconf.

      2. 2

        Everyone keeps referencing Buck and Bazel. How do they compare to Meson, which GTK just switched to?

        1. 3

          My understanding (which is based only on reading Meson docs, not actually using it) is that Meson is more similar to CMake, which is all about integrating with things present in your system environment for building system software.

          Buck and Bazel take a different approach: they’re all about fully encapsulated builds that depend on nothing outside the project directory. This is great for people who are building software for deployment with big teams (nothing depends on a given engineer’s machine config, mostly) but not great for packagers who are building software for binary distribution to desktop machines, who want integration with system-installed packages.

          Meson is to Bazel as Debian packaging is to Docker; one tries to be a nicer way to integrate with systems we’ve had for a long time, while the other throws its arms up in the air and says “fuck it, the rest of this machine might as well not exist”.

          1. 1

            Reading very quickly, it looks like the input to meson is very similar to Buck and Bazel, but it generates ninja files instead of trying to do everything, and it actually contains the tools you need to do the usual install steps.

            Buck definitely had nothing similar to make install, and the last time I looked at it, it couldn’t even use third party libraries installed on your system – you had to put them into your build directory.

            1. 1

              Buck definitely had nothing similar to make install, and the last time I looked at it, it couldn’t even use third party libraries installed on your system – you had to put them into your build directory.

              This is by design. Buck builds should be reproducible.

              Regarding install, Buck + Bazel are for building code, rather than installing packages. The idea is that your build scripts reproducibly create binaries which can then be packaged as .deb etc.

              1. 1

                This is by design. Buck builds should be reproducible.

                It’s also completely useless for the vast majority of software software, which wants to use installed libraries.

          2. 2

            I enjoy Make as a very limited form of logic programming (“every dependency is a precondition to build a target”), but I feel severely handicapped by the only available predicate: “is this file newer than another file” and general lack of debugging capabilities (“make -d” seems a bit overwhelming).

            1. 0

              Make leans too heavily on Bash to make maintainable builds possible. Sure, it’s fine if you are just compiling a few files, but for anything larger please use something declarative like Buck, Bazel and co.

              1. 2

                Make leans heavily on Bash specifically, or /bin/sh ?

                The first would be a definite issue. The second - not so much. Posix shell scripting concepts are well defined.

                When involved as /bin/sh is in posix compatibility mode, and on Debian & derivatives, /bin/sh is Dash, not Bash.

                1. 1

                  There are many, many different versions of make, and not all of them depend on bash. I’ll give you that they all depend on a sh-compatible shell, though, by way of it’s use of system(3).

                  edit: of course, this is often customizable in implementations, e.g. Via .ONESHELL, or other mechanisms, so maybe splitting hairs.

                  1. 3

                    It’s not just about the Bash dependency, it’s also about having semantic information in the target graph. For example, in Buck you can declare a C++ library without writing code up-front that decides how it should link, which compiler to use, which flags, etc. Yes, you could implement this in Make using Bash + Clang, but it would be tedious and error-prone. I find that it’s just easier to use a build system that understands my code!

                    If you choose not to use the language-specific features, Buck and Bazel are just a better Make (hashes not timestamps, non-recursive, better syntax, etc. ). https://buckbuild.com/rule/genrule.html

                    1. 3

                      My fault with your point was that make doesn’t really rely on anything–it’s dumb. A programmer setting up a build system with make, as you state, has a lot of hoops to jump through, possibly by using bash, or other utilities. Basically, I agree with you, but was splitting hairs about the wording.

                      To address your other, more important point, though. I think the reason that people still suffer through all the hurdles to make make work, is because it’s readily available everywhere. Scons, which was a nice system, never saw critical mass because (among other things) it was an extra dependency, and as a result an extra step and hassle for everyone. We need important, high profile projects (like GTK switching to Meson), to switch to a tool, and have that tool emerge as the new make before this problem will get better. I fear that the fact we have more and more tools emerging will just lead people back to make, though.

                      1. 1

                        Yes, I think we basically agree. I just wanted to emphasis how Make in practice requires you to call lots of tools. Upvoted :)