It's still 100% relevant. I can only speak for FreeBSD, but this is a real pain when building from source (outside of FreeBSD Ports).
Unhappily though, I think there are further portability issues, namely that when I create my BSDmakefile I am not sure that all the features I use would work with the versions of Make that come with OpenBSD, NetBSD, etc.
I mean, largely I don't do anything too crazy or fancy but the feeling is always there and I don't really have time/inclination to test every change with OpenBSD, NetBSD, etc since I don't normally use any of those other operating systems in the BSD family aside from FreeBSD which I do use.
For the last few years I've been using C less though, as I prefer Rust anyway. And for the times when I do end up creating a makefile I now usually create only a GNUmakefile. Supporting only GNU Make feels a little bad but I think in most cases people will have it installed even on FreeBSD, and at least naming it as GNUmakefile like is being suggested and as I am doing, does not waste peoples time trying to run other implementations of Make with those projects even if it might annoy them to install GNU Make.
A suggestion for naming makefiles GNUmakefile is a funny try to borderline, but it is late for around two decades and cannot have effect beyond boring. In technical terms, it is easier to rename BSDmakefiles rather than millions of projects out there.
It is not on a number of platforms that enjoy popular usage.
> In technical terms, it is easier to rename BSDmakefiles rather than millions of projects out there.
GNU is not the standard. Generally it's a superset of it; if so, then it should have the onus of the nonstandard name.
- Rename non-gnu makefiles of a specific platform (tedious but possible),
- Rename gnu makefiles in the entire internets (0% chance),
- Continue insisting to no avail (requires no effort).
>if so, then it should
A wonderful world where such implications always work, but not where we live.
The solution, like the other people were saying, is to name the makefile as GNUmakefile if it is using GNU Make specific features.
[citation needed] Gnu make is a superset of posix compatible make standard.(with very few exceptions) It shouldn't break. If it breaks, I think it's a bug, and the makefile should be altered into posix-compliant compatibility with gnu make.
>[citation needed]
From OpenBSD make(1) manpage: "The handling of ‘.depend’ is a BSD extension."
Considering it's the default on the OS I'm using to post this (OpenBSD) I'd regard it as fairly standard.
On top of that you want to rewrite all of the Makefiles for other implementations of Make, that exist on systems where the implementation of Make that is included with the system is not GNU Make, so that the system still works after you've switched out the implementation of Make that came with the system with GNU Make.
...
Why?
Why should everyone else do a bunch of extra work just so that the projects using GNU Make can keep using GNU Make specific features, when literally all those people using those GNU Make features had to do was to rename their Makefile to GNUmakefile and it would keep working for them when they invoke GNU Make just the same way they did before and would not cause confusion for others?
Of course the "recursive make considered harmful" paper also articulates pretty well why such a usage may have its own problems. http://aegis.sourceforge.net/auug97.pdf