RE: New conditional assignm ent facility

On Monday, January 29, 2024 5:18 AM, Edward Welbourne wrote: >rsbec...@nexbridge.com (27 January 2024 23:45) wrote: >> My take on it is that +:= (because of the : ) means that you have to resolve >everything at that point. > >Surely it could equally mean: fully expand the right-hand side immediatel

RE: New append operators (was: Re: New conditional assignment facility)

On Sunday, January 28, 2024 5:36 PM, Paul Smith wrote: >On Sat, 2024-01-27 at 17:45 -0500, rsbec...@nexbridge.com wrote: >> My take on it is that +:= (because of the : ) means that you have to >> resolve everything at that point. > >Yes, I understand what you are saying. The question is, is that t

RE: New conditional assignm ent facility

On Saturday, January 27, 2024 4:14 PM, Paul Smith wrote: >On Sat, 2024-01-27 at 15:52 -0500, rsbec...@nexbridge.com wrote: >> > I'm interested in peoples' opinions about which of these two >> > implementations they would feel to be more "intuitive" or "correct". >> > Also please consider issues of

RE: New conditional assignm ent facility

On Saturday, January 27, 2024 3:33 PM, Paul Smith wrote: >On Mon, 2024-01-22 at 08:15 -0500, Paul Smith wrote: >> Let's step back and I'll try to think more clearly about this. > >Sorry for the delay in replying. > >I can see that I was thinking about this one way but there's another way to >look

RE: Handling references to invalid variables

On Monday, February 20, 2023 2:50 PM, Paul Smith wrote: >On Mon, 2023-02-20 at 14:20 -0500, rsbec...@nexbridge.com wrote: >> I think you need to be able to return to a compatible mode for some >> users. Having an option like --undefined-variables=warn or -- >> undefined-variables=error (the default

RE: Handling references to invalid variables

On February 20, 2023 2:11 PM, Paul Smith wrote: >In the next major release (not the upcoming 4.4.1 release but the one after >that) I >plan to implement notifying users of invalid variable references; for example >variable names containing whitespace. > >So, a makefile like this for example: > >

RE: shell function: confusing error when shebang incorrect

On October 9, 2022 11:16 AM, Kirill Elagin wrote: >There is a bit of unexpected behaviour in the `shell` function (due to the >undocumented fact that it sometimes avoids actually calling the >shell): > >``` >$ cat Makefile >FOO:=$(shell ./foo.sh) > >$ cat foo.sh >#!/bin/ohno >echo hi > >$ make >mak

RE: [PATCH] Port to 32-bit long + 64-bit time_t

On October 3, 2022 3:56 PM, Paul Eggert wrote: >On 10/3/22 09:12, rsbec...@nexbridge.com wrote: >> This happens in AR and TAR also, which appear to be limited to 32-bit time_t >> on >some platforms. It's a struggle but we have some time to deal with it. > >Yes, I've been part of an ongoing effort

RE: [PATCH] Port to 32-bit long + 64-bit time_t

On October 2, 2022 8:07 PM Paul Eggert wrote: >On 10/2/22 14:09, Paul Smith wrote: > >> I applied these changes but made a few mods: > >Thanks. I assume you'll push this to savannah at some point? I had been working >on merging with your more-recent changes to GNU Make, and it wouldn't hurt to >hav

RE: [PATCH] Port to 32-bit long + 64-bit time_t

On October 2, 2022 6:13 PM, Paul Smith wrote: >On Sun, 2022-10-02 at 17:48 -0400, rsbec...@nexbridge.com wrote: >> > I understand that this type of reuse makes things easier for the >> > gnulib folks, but for GNU make I'm not ready to drop support for >> > platforms that are not POSIX enough to run

RE: [PATCH] Port to 32-bit long + 64-bit time_t

On October 2, 2022 5:24 PM, Paul Smith wrote: >On Thu, 2022-09-22 at 11:00 -0700, Paul Eggert wrote: >> (This would not be needed if 'make' used Gnulib's inttypes module.) > >I would be happy to use it, if using it didn't import a ton of other things >that >require POSIX tools AND an already-worki

RE: Deprecating OS support

On October 1, 2022 3:01 PM, Paul Smith wrote: >On Sat, 2022-10-01 at 14:02 -0400, rsbec...@nexbridge.com wrote: >> The ITUGLIB project team maintains a port of GNU Make for currently >> supported HPE NonStop Guardian platforms. We do intend to port 4.4 >> when it is released. I am the official main

RE: Deprecating OS support

On October 1, 2022 1:03 PM, Paul Smith wrote: >With the upcoming release (4.4) I intend to announce that I'll be removing >support >for the following platforms in the next, post-4.4 >release: > > - OS/2 (EMX) > - Amiga > - Native MS-DOS > >For the first two, I suspect that whatever support we c

RE: [PATCH] Port to 32-bit long + 64-bit time_t

On September 21, 2022 8:58 PM, Paul Eggert wrote: >On 9/20/22 18:48, rsbec...@nexbridge.com wrote: >> I am sorry to say that the %j prefix is not safe or portable. There >> are major production platforms where this is not supported. I work on >> one of them. > >Which platform and version? I'd like

RE: [PATCH] Port to 32-bit long + 64-bit time_t

On September 20, 2022 5:22 PM Paul Eggert wrote: >Don't assume that time_t fits in long, as some hosts (e.g., glibc x86 - >D_TIME_BITS=64) have 32-bit long and 64-bit time_t. >This fix uses C99 sprintf/scanf %jd and %ju, which is safe to assume nowadays. I am sorry to say that the %j prefix is not

RE: [bug #62654] Add z/OS support

On July 3, 2022 7:33 PM, Paul Smith wrote: >I prefer to do the review via email rather than in the Savannah bug tracker >which >has pretty annoying markup. > >I would appreciate a somewhat comprehensive commit message or ChangeLog for >this set of patches, at least explaining some of the less obvi

RE: [bug #61594] suggest new $(hash ...) function

On December 2, 2021 4:20 AM, Boris Kolpackov > rsbec...@nexbridge.com writes: > > > Sadly, the import restrictions do not distinguish between message > > digests and cryptography [...] > > You seem to be quite knowledgeable on the matter so can you provide one > concrete example of where one jur

RE: [bug #61594] suggest new $(hash ...) function

On December 2, 2021 3:44 AM, Edward Welbourne > > My first counter-argument comes from the "$(shell git hash-object obj)" > > suggestion which begs the question: if git, which relies heavily upon > > SHA-1, is available, doesn't that mean SHA-1 is also natively > > available? I'm not aware of git b

RE: GPL Interpretation on load [Was: [bug #61594] suggest new $(hash ...) function]

On December 1, 2021 9:41 AM, Eli Zaretskii wrote: > To: rsbec...@nexbridge.com > Cc: bug-make@gnu.org; bo...@kolpackov.net > Subject: Re: GPL Interpretation on load [Was: [bug #61594] suggest new > $(hash ...) function] > > > From: > > Cc: , , m...@gnu.org>, > > > > Date: Wed, 1 Dec 202

RE: [bug #61594] suggest new $(hash ...) function

On December 1, 2021 9:42 AM, anonymous wrote: > These are all good and useful points, thanks. However, some counter- > arguments: > I tried to be careful to distinguish "cryptographic" from "low-collision-rate- > hash" in the original description because I absolutely do not want to > "introduce cry

RE: GPL Interpretation on load [Was: [bug #61594] suggest new $(hash ...) function]

On December 1, 2021 9:25 AM, Eli Zaretskii wrote: > > From: > > Date: Wed, 1 Dec 2021 09:09:55 -0500 > > Cc: bug-make@gnu.org, bo...@kolpackov.net > > > > On December 1, 2021 9:06 AM, Tim Murphy wrote: > > > > > > > -load $(XTRA_OUTPUTDIR)/hash$(XTRA_EXT) > > > > This thread brings up a question.

GPL Interpretation on load [Was: [bug #61594] suggest new $(hash ...) function]

On December 1, 2021 9:06 AM, Tim Murphy wrote: > -load $(XTRA_OUTPUTDIR)/hash$(XTRA_EXT) This thread brings up a question. The load function checks for GPL compatibility. /* Assert that the GPL license symbol is defined. */ symp = (load_func_t) dlsym (dlp, "plugin_is_GPL_compatibl

RE: [bug #61594] suggest new $(hash ...) function

On December 1, 2021 9:06 AM, Tim Murphy wrote: > On Wed, 1 Dec 2021 at 12:37, Edward Welbourne > wrote: >> mailto:rsbec...@nexbridge.com (1 December 2021 13:08) wrote: >>> I would suggest that adding cryptography to GNU Make would limit its >>> reach. There are jur

RE: [bug #61594] suggest new $(hash ...) function

On November 30, 2021 11:37 PM, anonymous wrote: > To: psm...@gnu.org; bo...@kolpackov.net; bug-make@gnu.org > Subject: [bug #61594] suggest new $(hash ...) function > > URL: > > > Summary: suggest new $(hash ...) function >

RE: [PATCH 3/3] Introduce $(compare ...) for numerical comparison

On November 10, 2021 12:19 PM, Jouke Witteveen wrote: > To: psm...@gnu.org > Cc: bug-make > Subject: Re: [PATCH 3/3] Introduce $(compare ...) for numerical comparison > > On Mon, Nov 8, 2021 at 4:08 PM Paul Smith wrote: > > > > On Fri, 2021-07-16 at 14:04 +0200, Jouke Witteveen wrote: > > > +@it