Mostly nothing, but writing a makefile and only evaluating against it makes it difficult to guarantee that you will see the same behaviour on a non-GNU system (which has become more relevant these days as even systems based on the Linux kernel are no longer guaranteed to run a GNU userland). What makes matters worse is that even if you grab a BSD make implementation (there are several), there are no guarantees there either, although the number of non-POSIX extensions are far far fewer. Thus you are left to committing things to memory and it is not easy to get it right.
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.
> but writing a makefile and only evaluating against it makes it difficult to guarantee that you will see the same behaviour on a non-GNU system
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".
You are being overly defensive here. What I wrote had nothing to do with GNU in particular, as I hope I made clear in the very next sentence after the one you cited by stating that the same is true for BSD make implementations and portability. The parent asked about GNU make, thus I logically kept on talking about GNU make.
I misinterpreted the whole thread as "what's wrong with writing makefiles for GNU make specifically".
Which is subtly a different question (and to which the answer of course is "nothing, as long as you're happy to specifically use GNU make to run them").
Thank you! I was not aware of ibara’s port of OpenBSD’s m4, so now I can drop my own ugly 15-minute hack. Is there a good source for finding strict POSIX tools rather than just go digging?
Sad sidenote on m4, that even with strict POSIX [1], you still have no clue if `define` will turn into “” or “define” due to a split between AT&T on one hand and GNU and BSD (all of them?) on the other that POSIX did not rule one way or the other. It gets even worse when you realise that some m4 implementations have “constants” like `windows` so that “Stained glass windows” can turn into “Stained glass 0”. But I guess this can be expected when you are dealing with a tool that has evolved in multiple directions since 1977?
> Is there a good source for finding strict POSIX tools rather than just go digging?
Some communities(iglunix, kisslinux, carbs linux, wyvertux, oasis linux, ...) are actively researching alternatives to the "standard" coreutils. You could check what they use, perhaps you'll find something interesting and strict. But general source is digging of course :)
> But I guess this can be expected when you are dealing with a tool that has evolved in multiple directions since 1977?
Exactly. 100% conformance isn't always possible, especially when standard is unclear on some things.
I didn't know about these projects; GNU-less Linux is something I've wanted for a long time. Thanks. Are there any other projects you know of (as indicated by your ellipsis)?
Solaris had all the POSIX userland tools separated from the Sun mainline versions in the /usr/xpg4 and xpg6 directories. They can be a source for replacements.
The wrong part in GNU make is that it always permit using non-posix extensions regardless of .POSIX special target, while pdpmake does not. This fact makes pdpmake kinda special since it can be used for posix compliance testing, which is crucial part of developing portable application that uses make to build itself.
That's not wrong. It's something that not everybody will like, but as long as the extensions don't conflict with anything specified by POSIX, that is permitted.
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.
I agree that disabling will-be-posix extensions in POSIX mode sounds like an extreme idea, but seriously, such strictness is the main point of the pdpmake. It ensures that implementation conform to the current standard, not draft which may change quite often.
It turns out it's actually pdpmake-build-time-configurable. If you build with -DENABLE_FEATURE_MAKE_EXTENSIONS -DENABLE_FEATURE_MAKE_POSIX_202X, extensions are enabled by default, and .POSIX only flags non-POSIX-202x extensions. I don't know what, if anything, this says about the main point of pdpmake, but I'm glad with this mode.
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.