8 ms·

Public domain POSIX make

73 points by donmcc 4y ago

bragr 4y ago
>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.
- CorrectHorseBat 4y ago
  Afaik it's Germany (and maybe some othes) where that is an issue https://en.m.wikipedia.org/wiki/Public_domain#cite_ref-CC0_58-0 https://en.m.wikipedia.org/wiki/Public_domain#cite_ref-CC0_5...
- naniwaduni 4y ago
  I'm not sure I'd like to meet the court that wouldn't see a public domain dedication and round it up to a maximally permissive license if it ever came up anyway.
- saagarjha 4y ago
  I thought that was a problem for other countries? In the US I’m pretty sure dedicating something to the public domain actually places it there.
  - bragr 4y ago
    Nope. I think people are misunderstanding the difference between courts interpreting "putting something in the public domain" as a permissive license and actually severing the copyright from your legal person. There's no current provision for severing those rights under the current law so it may be possible for them (or their heirs) to claw a work back from the public domain using copyright termination/relicensing provisions of the law [1]. 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-put-anything-public-domain-why-that-needs-to-change/ https://www.techdirt.com/2015/01/23/why-we-still-cant-really...
- cchcxsvvb 4y ago
- t-3 4y ago
  Considering that this is source-available software used for building other software, license is near meaningless anyway. Who distributes their build toolchain?
  - klez 4y ago
    > Who distributes their build toolchain? Operating Systems, for one.
dwheeler 4y ago
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 turn out to be useful, and it runs practically everywhere. Your mileage may vary.
- ori_b 4y ago
  > Extensions from a future POSIX standard have been added. Note that these are subject to change until the standard is finally published. The extensions listed cover most of what I'm currently missing from posix make.
- hvdijk 4y ago
  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-Search.html 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 ./configure && make).
  - zxwrt 4y ago
    But out-of-tree builds feature is optional, right?
    - hvdijk 4y ago
      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.
- chubot 4y ago
  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/ 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 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!
azalemeth 4y ago
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.
ainar-g 4y ago
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/ https://pubs.opengroup.org/, but couldn't.
- ainar-g 4y ago
  To answer my own question, if this[1] StackExchange to be believed, you need to join the mailing list of something called “The Austin Group”. Although some fairly informative meeting minutes are available publicly here[2]. [1]: https://unix.stackexchange.com/q/607333/105635 https://unix.stackexchange.com/q/607333/105635 [2]: https://www.opengroup.org/austin/docreg.html https://www.opengroup.org/austin/docreg.html
  - jcranmer 4y ago
    And from the most recent minutes: > Bug 805: Add Make conditionals Rejected > https://austingroupbugs.net/view.php?id=805 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.
    - ainar-g 4y ago
      To be fair, if you need conditionals in target bodies, you're probably better off putting the body into a separate file as a shell script. And if you need conditionals in macros, there's the old macro-in-macro approach: DEBUG = 0 DEBUG_FLAG_0 = DEBUG_FLAG_1 = --debug # … main.bin: 1.o 2.o # … build $(DEBUG_FLAG_$(DEBUG)) -o main.bin # … I'm not saying that it's a good way, but it is a way.

73 points by donmcc 4y ago

>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.

CorrectHorseBat 4y ago
Afaik it's Germany (and maybe some othes) where that is an issue https://en.m.wikipedia.org/wiki/Public_domain#cite_ref-CC0_58-0 https://en.m.wikipedia.org/wiki/Public_domain#cite_ref-CC0_5...
naniwaduni 4y ago
I'm not sure I'd like to meet the court that wouldn't see a public domain dedication and round it up to a maximally permissive license if it ever came up anyway.
saagarjha 4y ago
I thought that was a problem for other countries? In the US I’m pretty sure dedicating something to the public domain actually places it there.
- bragr 4y ago
  Nope. I think people are misunderstanding the difference between courts interpreting "putting something in the public domain" as a permissive license and actually severing the copyright from your legal person. There's no current provision for severing those rights under the current law so it may be possible for them (or their heirs) to claw a work back from the public domain using copyright termination/relicensing provisions of the law [1]. 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-put-anything-public-domain-why-that-needs-to-change/ https://www.techdirt.com/2015/01/23/why-we-still-cant-really...
cchcxsvvb 4y ago
t-3 4y ago
Considering that this is source-available software used for building other software, license is near meaningless anyway. Who distributes their build toolchain?
- klez 4y ago
  > Who distributes their build toolchain? Operating Systems, for one.

dwheeler 4y ago

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 turn out to be useful, and it runs practically everywhere. Your mileage may vary.

ori_b 4y ago
> Extensions from a future POSIX standard have been added. Note that these are subject to change until the standard is finally published. The extensions listed cover most of what I'm currently missing from posix make.
hvdijk 4y ago
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-Search.html 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 ./configure && make).
- zxwrt 4y ago
  But out-of-tree builds feature is optional, right?
  - hvdijk 4y ago
    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.
chubot 4y ago
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/ 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 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!

azalemeth 4y ago

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.

ainar-g 4y ago

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/ https://pubs.opengroup.org/, but couldn't.

ainar-g 4y ago
To answer my own question, if this[1] StackExchange to be believed, you need to join the mailing list of something called “The Austin Group”. Although some fairly informative meeting minutes are available publicly here[2]. [1]: https://unix.stackexchange.com/q/607333/105635 https://unix.stackexchange.com/q/607333/105635 [2]: https://www.opengroup.org/austin/docreg.html https://www.opengroup.org/austin/docreg.html
- jcranmer 4y ago
  And from the most recent minutes: > Bug 805: Add Make conditionals Rejected > https://austingroupbugs.net/view.php?id=805 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.
  - ainar-g 4y ago
    To be fair, if you need conditionals in target bodies, you're probably better off putting the body into a separate file as a shell script. And if you need conditionals in macros, there's the old macro-in-macro approach: DEBUG = 0 DEBUG_FLAG_0 = DEBUG_FLAG_1 = --debug # … main.bin: 1.o 2.o # … build $(DEBUG_FLAG_$(DEBUG)) -o main.bin # … I'm not saying that it's a good way, but it is a way.