Using Make – writing less Makefile

I admittedly don't have a ton of experience with make, but what's the point of doing this vs just throwing the compile commands in a shell script?

Make is fantastic. I’m using it to rebuild and run containers in my development environment, and to build a full repository of RPM packages (that my project needs and which CentOS Stream lacks). I suppose that if javascript tooling was more amenable to process one file at a time, I could do parallel transpiling and bundling of a hefty frontend with make as well.

I also use its metaprogramming and late evaluation capabilities a lot, heavily inspired by the tricks Buildroot is doing.

If you are mindful of its restrictions (it works with “words” separated by spaces, thus paths with spaces in them are a problem unfixable without severely breaking backward compatibility; and your targets need to be expressible as files with meaningful modification timestamps), it’s a very powerful tool. It deserves more appreciation.

Make will automatically do all the steps, and stop if any one fails. Of course you van do manually, but is much more work.

Gonna get downvoted to oblivion for saying this but I haven't hated a tool more than make.

Discovering the dependencies depends on the compilers, not on the platform.

I have stopped using MSVC many years ago, so I do not know how it handles dependencies, but with gcc or clang that works regardless of platform, with compiler-specific options.

Moreover, software for one platform can be built on another platform. What matters is only the platform used for building, where the compilers are hosted, not the target platform for the built software.

In general, I extract all platform specific definitions, like the names of the compilers and their command-line options in platform-specific Makefiles, which include a generic Makefile with platform-independent definitions, rules and make targets. Any platform-specific details, like SDK paths, are encapsulated in the definitions of certain "make" variables.

While I have not needed to update the platform-independent generic Makefile for decades, the platform-dependent sections need updates from time to time, but that is not done for every software project, but perhaps once per year or more seldom, when significant new compiler versions, standard libraries or other new software tools become available.

I have not seen yet any reason for using Ninja. Perhaps it may be faster when building something like chrome, but because chrome is likely to be the slowest-compiling software project known to mankind, it is hard to tell how much is gained by Ninja. For software projects of more typical sizes I have not seen noticeable advantages of Ninja. Traditional make can keep all the cores of a CPU 100% busy, so there is no way any other building system can be appreciably faster. There are some very bad Makefiles that are intrinsically slow, but that is a problem of those Makefiles, not of "make" in general.

Using a minimum project-specific Makefile section can only simplify debugging, not making it difficult.

I have never seen any evidence for the claim that cmake scales better. On the contrary, at least in all the open-source software projects that I have ever seen cmake is a major source of bugs in the building process that nobody knows how to fix. (i.e. after some software updates cmake fails to find files that exist, presumably due to some errors in the cmakelists that appear to be arcane enough that they are hard to find) I have never seen in projects that use traditional make such errors that are so frequent in all the projects that use cmake.

I have a lot of experience in building software projects, because for many decades, with the exception of a few professional programs without alternatives, I have been using only programs that I compile from sources. Most projects have very bad Makefiles, which are very hard to maintain, i.e. to change when files are added, deleted, moved or renamed, but at least they build the software projects reliably. Whenever cmake is used, building a new version is always an adventure with unpredictable outcome.