[bsdubernerd]

I do the same for projects I'm looking at, and I'm on linux. Gives a good understanding of the thing you're looking at. There are many things you can tell by looking at the build process.

There are some things I do not agree with the author though.

Pure make: I think it's refreshing to see, nowdays. Many autotools projects do not do ANY configuration, and could actually use just make in most cases. But the authors just jumped at the "autoconf/cmake" bandwagon, because they probably were never familiar with make, or just want to follow conventions (which is ok, I guess).

Fixing a make build is leaps and bounds easier than to fix compared to cmake or autotools. If you follow the "standard" C environment variable conventions a makefile can be extremely portable (I've written stuff myself supporting osx/linux/bsd/irix/aix for several years). Vanilla make doesn't support variant builds, but if you ever need that (and are willing to believe that make is not rotten as many people seem to suggest), I suggest you look at makepp.

There's no date on the article, but a common incumbent to cmake these days is meson. As a dev, I'm still conflicted between these two: meson has a superior syntax and less baggage, but everything else seems inferior to me at the moment, especially the documentation.

Building from source also gives you an idea of how the author is managing dependencies, which ones were chosen, and so on.

A big one for me is how I still consider a package with two external (that you have to build yourself), robust dependencies much better than 20 smaller cargo-managed crates that require 300mb to build, or ~100 packages pulled by tox when you actually _need_ to contribute to the python package...

This is great way to weed off between multiple candidate projects when you have the luxury of doing so.

[mid-kid]

> But the authors just jumped at the "autoconf/cmake" bandwagon, because they probably were never familiar with make, or just want to follow conventions (which is ok, I guess).

I'd personally recommend everyone use autoconf or cmake (or even better these days, meson) over straight make for the "conventions" purpose if anything. It's very easy to forget build system features that downstream linux distributions and package managers rely on. This includes but isn't limited to setting installation paths (this includes bindir, sbindir, libdir (especially important for multilib), and even mandir, docdir and infodir. don't just assume they're under share/ or share/ even exists!), proper cross-compilation support/detection, inheriting CFLAGS and other variables to set the path for certain programs, and a lot of more minute details.

It saves a lot of time downstream when all the packages can be built using the same script, as a lot of time is wasted on patching custom build systems. Even autotools and cmake (and meson) aren't always perfect at preventing developers from breaking one of their features through e.g. hardcoding/misuses of features, but it's at least less common, as they provide the mechanisms to conform easily.

Hell, even if you use a regular makefile as your "main" build system for personal convenience reasons, it's very appreciated if you can provide at least one of autotools/cmake/meson as an alternative for your friendly neighbor distribution maintainer, lest you end up with a perl-cross-make situation[1].

[1]: https://arsv.github.io/perl-cross/