4 ms·

Genuine question: what's wrong with GNU make?

zxwrt 4y ago
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.
- hvdijk 4y ago
  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.
  - zxwrt 4y ago
    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.
    - hvdijk 4y ago
      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.
ninjin 4y ago
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.
- zxwrt 4y ago
  awk: nawk aka one true awk sed: sbase sed m4: https://github.com/ibara/m4 https://github.com/ibara/m4
  - ninjin 4y ago
    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? [1]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/m4.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/m...
    - zxwrt 4y ago

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.

hvdijk 4y ago
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.
- zxwrt 4y ago
  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.
  - hvdijk 4y ago
    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.

ninjin 4y ago

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.

zxwrt 4y ago
awk: nawk aka one true awk sed: sbase sed m4: https://github.com/ibara/m4 https://github.com/ibara/m4
- ninjin 4y ago
  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? [1]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/m4.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/m...
  - zxwrt 4y ago