Makefiles, at least in my corner of the industry, are exceedingly common for projects with a build process of medium-to-low complexity.
Then again, if your build should output a .nupkg, the whole infrastructure seems to be lacking. You are left alone doing things that seem like they should be part of a package manager. e.g. handling of the version number. The whole build system knows the build output, but you have to specify it by hand again, in a different file.
I don't know what GNU/Linux you're using, because in my experience, most packages going into a distro use make.
Oh, and then there is that whole denominator in the GNU/Linux fraction that's built with GNU Make.
Maybe you don't see Makefiles because you're relying on binary packages?
no, they use autotools or cmake, which happens to generate makefiles. the package authors themselves definitely don't write any makefiles by hand except maybe for trivial packages (and frankly I'm not sure)
Also note that not all Autotools-based projects use Automake. Using only Autoconf, with a hand-maintained Makefile, is a thing.
The goal of Autotools is to produce a software distribution that doesn't require the end user to have Autotools. The end user has a shell to run the configure script, and that's it. If that works, they run "make".
About the most sophisticated generation the user will see is that some Makefile.in template is passed through sed to substitute @@XYZ@@ variables.
And coming back to Autotools, some of the largest Autotools projects (see the GNOME ecosystem) has been moving/moved to Meson, which can also be used to generate Ninja rules instead of Makefiles.
CMake Generators: https://cmake.org/cmake/help/latest/manual/cmake-generators.... Meson: https://mesonbuild.com/ Bazel: https://bazel.build/
GNOME and Meson: https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting
That's what all build systems do. Hell, cmake's description is "cross-platform Makefile generator".
The rationale is quite obvious: the DAG part is solved problem. The hard part is extracting platform-dependent info, perform validations, and use it to generate the DAG.
And a Makefile is a DAG.
I've gotten rid of several of our pre modern cmake functions, but more remain.
so how do you propose to do code generation, parsing stuff like /etc/lsb_release to work around a bug for people building under ubuntu 16.04, or that kind of thing ?
Ideally the official Find... packages should not make use of deprecated CMake functionality, they should be actively maintained to follow the current best-practices, so that they can serve as examples of the right way to do it.
As I rambled about in my longer comment yesterday, this kind of work shouldn't require you to think, it should just be an exercise in applying boring, samey, dependable boilerplate.
^ Is that a good one?
I honesty have no idea how some people come up with these absurd comparisons. I mean, who in their right mind feel is appropriate to compare a Makefile with a build system? And how clueless about things are "in the Linux world" do you need to be to claim that Makefiles are how people build software in Linux?
I mean, I've been using Linux for a couple of decades now and I can't remember the last time I saw a project that relied on Makefiles to build. At best projects use some kind of Makefile generator. The ancient ones use autotools and even those are going the way of the dodo.
> CMake allows us to handle almost all those things right except one - it doesn’t have return values
This is a red flag. If you're hoping to write functions with cmake... You're doing it wrong. Very wrong. You add targets, and you add rules to the target. If you find yourself wanting to do anything other than this then you should take a step back and read a modern cmake tutorial again, because odds are you're doing it wrong.