Genuine question: what's wrong with GNU make?
Public domain POSIX make
11–20 of 41 posts
Re: Public domain POSIX make
#12Genuine question: what's wrong with GNU make?
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.
Re: Public domain POSIX make
#13Genuine question: what's wrong with GNU make?
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.
Re: Public domain POSIX make
#14Sadly, the POSIX specification for "make" is notoriously limited. They only spec'ed what everyone could agree on, and that wasn't much. I'm sure there are cases where a make that only implements the POSIX spec is fine.. and if this is useful, great!! However, many projects that use "make" will outgrow it. I think many people just assume GNU make when they use a make; GNU make has lots of additional capabilities that…
Even for those that do not assume GNU make, this may not be enough. GNU Autotools are not limited to running on GNU make, but this make does not implement everything used by Autotools. The first thing I noticed it does not handle is VPATH ( https://www.gnu.org/software/make/manual/html_node/General-S... ) which is used by Autotools for out-of-tree builds (mkdir build && cd build && ../configure && make as opposed to…
But out-of-tree builds feature is optional, right?
Re: Public domain POSIX make
#15Genuine question: what's wrong with GNU make?
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…
awk: nawk aka one true awk
sed: sbase sed
Re: Public domain POSIX make
#16Genuine question: what's wrong with GNU make?
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.
Re: Public domain POSIX make
#17Sadly, the POSIX specification for "make" is notoriously limited. They only spec'ed what everyone could agree on, and that wasn't much. I'm sure there are cases where a make that only implements the POSIX spec is fine.. and if this is useful, great!! However, many projects that use "make" will outgrow it. I think many people just assume GNU make when they use a make; GNU make has lots of additional capabilities that…
Yeah I'm left scratching my head at the purpose of this project.
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!
Re: Public domain POSIX make
#18Earlier quoted context omitted.
Even for those that do not assume GNU make, this may not be enough. GNU Autotools are not limited to running on GNU make, but this make does not implement everything used by Autotools. The first thing I noticed it does not handle is VPATH ( https://www.gnu.org/software/make/manual/html_node/General-S... ) which is used by Autotools for out-of-tree builds (mkdir build && cd build && ../configure && make as opposed to…
But out-of-tree builds feature is optional, right?
It depends on the package. As far as Autotools itself are concerned, yes, users are free to choose whether to do in-tree or out-of-tree builds, but some packages require one or the other.
Re: Public domain POSIX make
#19Earlier quoted context omitted.
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…
awk: nawk aka one true awk sed: sbase sed m4: https://github.com/ibara/m4
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/m...
Re: Public domain POSIX make
#20Earlier quoted context omitted.
awk: nawk aka one true awk sed: sbase sed m4: https://github.com/ibara/m4
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 w…
> 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.