If your makefiles use gnu-isms (which is a valid choice) then I would lean towards using GNUmakefile and have Makefile call gmake - and don’t forget to use $(MAKE) for any recursion.
This is less fragile and requires less dependence on replacing make in the $PATH.
GNU Make's got tons of features that aren't in POSIX Make (so does BSD Make).
I use GNU-specific Makefile features all the time - here's a list of some of the cool features:
- Built-in functions (see https://www.gnu.org/software/make/manual/html_node/Functions.html for a list)
- User-supplied functions
- Much better pattern substitution
- Ways to tell Make that some files can be skipped in certain cases (.INTERMEDIATE and .SECONDARY modifiers)
- Ways to adjust Make's behavior (SECONDEXPANSION, DELETE_ON_ERROR, ONESHELL)
As a software packager, I'd advocate for autotools or CMake over a raw Makefile every time (assuming your project is a library or some binaries).
But with that said, I use GNU Make all the time for
"glue automation" - like if I had a folder full of files that needed some processing, I'd probably write a Makefile instead of a shell script. I also use top-level Makefiles on projects that have their own build systems, so that I don't need to remember how they work every time. People use shell scripts for that stuff too, but Make is better IMO.
It annoys me quite a bit when someone decides not to use autotools or meson, or other standard build tools. I have a build system set up to build static packages for several architectures, and most of my packages are described like this:
And it does the right thing for all packages that use autotools.
If you roll out your own Makefile, I have to figure out how to build the targets, how to install them, whether you use DESTDIR, whether you respect cross-compile options, how to build static library, how to configure your package... and code all this by hand to build() function.
The same goes for my custom Arch Linux packages.
Make the packagers job easy and just don't roll your own if you want your package to be distributed widely.
I was so hopeful for cmake in the early days, but have come to be a bit disappointed and avoid it everywhere I can. I shake my head in amazement at the project that spawned cmake (ITK, a medical imaging project) was using Tcl as an embedded scripting language (indeed, one of Tcl’s great features), then faced with needing a scripting language for their build system, decided to ad-hoc build one from scratch. Additionally (perhaps related), as a consumer of software that uses Cmake as its build infrastructure, I do not look fondly on the times I’ve had to debug what’s going on when the promised portability doesn’t work out on my systems. Perhaps it’d also be the same for an autotools build, or sufficiently complex vanilla Makefile, but Cmake does seem to a standout in my mind. This might be because I was so hopeful for it a dozen years ago, but I think the corner cases became too annoying because of their disappointing ad-hoc language, which was an avoidable mistake.
That all said, it’s still clearly managed to be important, and is indeed something the authors can be proud of, though I have personally come to find joy and good success in plain Makefiles.
I understand. In the past I used plain Makefiles too. GNU make is powerful. But it can get unpleasant and unreadably verbose pretty fast.
For personal projects I use either meson, or if they are sufficienlty complex (targetting multiple architectures in a single project and other tricky things) and the environment is known/fixed, I genereate build.ninja file from a PHP based configure script and it's unbeatable as to the flexibility, predictability and build speeds.
The best thing is that I can change anything and I can be sure that the incremental build will be the quickest and the result predictable. No more need for "make clean all" after changing some flags/variables in a Makefile.
It's the benefit meson/ninja combo will give you too, but meson is replaced by an actual well known programming language like PHP in my case.
For known environment builds, it's really nice. Much easier than fishing around the web for random recipies on how to do stuff in m4/meson/autoconf/automake/whatever custom language someone invented.
I really love the intentional simplicity of ninja build.
Could do all that, but FreeBSD could also have GNU make as the standard "make". I know there's some "license purity" reason why they don't want to do that, but don't expect everyone else to work around your self-imposed problem.
No, GNU devs should understand Unix beyond the GNU ecosystem. I'd be retired on my private planet if I had gotten a dime each time I ported Linux software (mostly the build system) to work on non-linux unixoid operating system.
To be fair: Nothing in GNUiverse teaches you interoperability; I too learned it the hard way when switching from Linux to BSD.
GNU is literally a platform. If you want to run the software on another platform (particularly one which is not as widely used as GNU) then you have to port the software.
isn't make older than gmake? it is normally gnu that adds extensions not compatible with the rest of the Unix world. making people believe sh == bash, make == gmake, m4 == gm4, and the list goes on for everything they touch.
To be frank, many of the GNU extensions are very useful. BSD tools have their own extensions over POSIX as well. Anyway, GNU software is FOSS and tends to be portable and so you can create something like GNU/FreeBSD or GNU/OpenBSD or whatever (Debian did it in the past). Naturally, the GPL/LGPL/etc. may not be "free" enough for the tastes of the BSD devs, but this is getting into politics.
Every Unix used to have its own implementation of those standard tools. They were often quite buggy and outdated (eg the C compiler that came with SunOS and Solaris in the mid 1990's only supported K&R syntax).
When installing Solaris, Sinix, AIX etc, you'd typically install the GNU tools immediately.
I understand the FreeBSD folks' frustration, though.
This is less fragile and requires less dependence on replacing make in the $PATH.