Public domain POSIX make • Hacker News Board

Re: Public domain POSIX make

#21

Post by zxwrt » Mon, Aug 01, 2022, 8:22 AM UTC

hvdijk wrote: post #16

zxwrt wrote: post #12

Earlier quoted context omitted.

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 the…

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.

Re: Public domain POSIX make

#22

Post by frankohn » Mon, Aug 01, 2022, 8:27 AM UTC

chubot wrote: post #17

dwheeler wrote: post #4

Sadly, 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 projec…

My experience aligns well with your. For any moderately complex project makefiles are inadequate and trying to make them work is a frustrating experience even in GNU make is pretty capable.

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.

Re: Public domain POSIX make

#23

Post by zxwrt » Mon, Aug 01, 2022, 8:33 AM UTC

frankohn wrote: post #22

chubot wrote: post #17

Earlier quoted context omitted.

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 projec…

My experience aligns well with your. For any moderately complex project makefiles are inadequate and trying to make them work is a frustrating experience even in GNU make is pretty capable. 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…

> To me the only downside of Meson is that it requires python but I can accommodate with that.

Check out https://git.sr.ht/~lattis/muon

Re: Public domain POSIX make

#24

Post by frankohn » Mon, Aug 01, 2022, 8:44 AM UTC

zxwrt wrote: post #23

frankohn wrote: post #22

Earlier quoted context omitted.

My experience aligns well with your. For any moderately complex project makefiles are inadequate and trying to make them work is a frustrating experience even in GNU make is pretty capable. 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…

> To me the only downside of Meson is that it requires python but I can accommodate with that. Check out https://git.sr.ht/~lattis/muon

Thank you, that looks interesting. I will check how it works with my projects.

Re: Public domain POSIX make

#25

Post by qznc » Mon, Aug 01, 2022, 9:02 AM UTC

frankohn wrote: post #22

chubot wrote: post #17

Earlier quoted context omitted.

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 projec…

My experience aligns well with your. For any moderately complex project makefiles are inadequate and trying to make them work is a frustrating experience even in GNU make is pretty capable. 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…

https://xmake.io/ kinda is Meson but with Lua instead of Python. Lua is embedded so no external dependency.

Re: Public domain POSIX make

#26

Post by frankohn » Mon, Aug 01, 2022, 9:28 AM UTC

qznc wrote: post #25

frankohn wrote: post #22

Earlier quoted context omitted.

My experience aligns well with your. For any moderately complex project makefiles are inadequate and trying to make them work is a frustrating experience even in GNU make is pretty capable. 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…

https://xmake.io/ kinda is Meson but with Lua instead of Python. Lua is embedded so no external dependency.

Thank you, that looks interesting too. In addition I like Lua because is much more light weighted than python and being embedded is nice to reduce dependencies.

The only problem I see is fragmentation. People are already considering cmake as the de facto standard despite all its flaws. If the cmake alternatives are too fragmented it will play in favor of cmake.

On the other side projects like xmake are interesting propositions. I will have a look at it in any case, thank you.

Re: Public domain POSIX make

#27

Post by kevin_thibedeau » Mon, Aug 01, 2022, 10:02 AM UTC

chubot wrote: post #17

dwheeler wrote: post #4

Sadly, 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 projec…

How do you do parallel builds with a shell script?

Re: Public domain POSIX make

#28

Post by kevin_thibedeau » Mon, Aug 01, 2022, 10:10 AM UTC

ninjin wrote: post #19

zxwrt wrote: post #15

Earlier 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…

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.

Re: Public domain POSIX make

#29

Post by klez » Mon, Aug 01, 2022, 10:34 AM UTC

t-3 wrote: post #8

bragr wrote: post #2

>This version is also dedicated to the public domain 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.

Considering that this is source-available software used for building other software, license is near meaningless anyway. Who distributes their build toolchain?

> Who distributes their build toolchain?

Operating Systems, for one.

Re: Public domain POSIX make

#30

Post by ainar-g » Mon, Aug 01, 2022, 11:35 AM UTC

That's pretty neat! But is there a link to the “future POSIX standard”? A few months ago I tried looking for it on https://pubs.opengroup.org/, but couldn't.