Your mileage may vary.
The extensions listed cover most of what I'm currently missing from posix make.
I wrote 3 GNU makefiles from scratch (a few hundred lines each) starting in ~2016 for https://www.oilshell.org/, and regret it. I switched to Python + Ninja, and I should have just used that all along.
So I think GNU make is already pretty old and regretted, and POSIX make even more so.
CMake + Ninja seems be pretty common these days, but for my project Python works fine, and is a lot simpler. CMake is also a bad (shell-like) language, but I'm pretty sure it's better and more featureful than GNU make (i.e. you're less likely to need to switch build systems/languages due to a new requirement)
This thread has some interesting experiences ... it does seem like there needs to be a better high level language to generate Ninja
https://lobste.rs/s/7svvkz/using_bsd_make#c_bfwcyc
Also, for portability I just generate a shell script instead of Ninja (even though Ninja is extremely portable and has multiple implementations now). For tarball distributions you probably don't need incremental builds.
All the user should need to compile software is a shell, not ANY make!
Ninja is a fine tool but it requires an higher level language to generate it's build files.
Cmake is just horrible, I just cannot stand it. I choose Meson instead and I am quite happy with it. Meson developers focus a lot on doing the right design decisions. They keep the language very simple and offer mostly one logical way to do a thing and Meson ensure it works right in every circumstance. Yet it offers advanced options when they are required but they are always well thought out.
If you compare meson to make at first you may think make is more flexible but ultimately it leaves to you many problems it doesn't solve and it turns out to be inadequate.
With make, declare automatically dependencies from header files? You are alone, that's your problem. There are some tricks using GCC but they looks like hacks. Maintain projects build logic across subfolders? That's your problem. Make only provide a very rough, inadequate mechanism.
Want to do parallel build by respecting dependencies across folder? Sorry, that's your problem but it may work using some tricks.
Want to build out of tree? Hmmm not supported in a standard idiomatic way. You need to use tricks.
How you create a static library in a cross-platform way? That's your problem. The same for shared libraries.
Personally I think that make is an obsolete tool whose design is inadequate very much like CVS that was replaced by git.
To me the only downside of Meson is that it requires python but I can accommodate with that.
> Bug 805: Add Make conditionals Rejected
> https://austingroupbugs.net/view.php?id=805
> As the behavior described in the desired action hasn't actually been implemented, to our knowledge, and there is insufficient consensus amongst the variants that have been implemented to pick one as the de facto standard this request is being rejected. Should the industry come to a consensus a new bug reflecting that should be filed.
TL;DR: no way forward for adding if/else statements to make for now.
With a strict POSIX implementation, you could develop against it and if it works correctly on your system it should also work correctly with pretty much any other make implementation out there.
Personally, I was so frustrated recently about this that I was looking for exactly what pdpmake offers and could not find anything. Thus I am now very thankful that I do not need to write it myself. But there is still plenty of room for strict POSIX tools like this for: awk, sed, m4, etc.
This would only be true if the entirety of thr GNU suite were necessary for GNU make to work. But it's not, so I always find this kind of argument really weird.
I mean it's not necessarily completely irrelevant criticism, but I somehow only see this level of criticism aimed at GNU tools.
I haven't seen many "you know let's make a variant of ninja because the current one is too ideological let's find another one that's still ninja but has slight differences that we 'all' agree are more basic or standardised somehow".
To me, the decision to let POSIX mode turn off extensions that are so widely available in other implementations that they have been approved for the next version of POSIX is an odd one. There is little reason not to already use those features today: using them is not going to seriously limit your portability. If you use them, you cannot also use pdpmake's POSIX mode. The obvious conclusion there, to me, is not to avoid using those features, but to avoid using pdpmake's POSIX mode.
IANAL but under US copyright law this is a meaningless statement as it's not possible to disclaim ownership. You can only permissively license - though reading the LICENSE file, this is what they are doing in practice.
The way copyright termination works is a big risk to opensource either way because in theory any open source license could be revoked after enough decades.
[1] https://www.techdirt.com/2015/01/23/why-we-still-cant-really...
