|
> 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/ |