[bug #65596] Test for let function not available in .FEATURES

Follow-up Comment #1, bug #65596 (group make): You're right. I guess it's too late to fix that now, since it will not be fixed in all releases that have the "let" function. You can test for its presence with the following construct: $(filter builtin,$(foreach let,unavailable,$(call let,,,builtin

[bug #65448] $(intcmp) problems with negative integers

Follow-up Comment #1, bug #65448 (group make): Indeed, it seems we currently compare magnitudes instead of values. I've attached a fix and regression tests. (file #55826) ___ Additional Item Attachment: File name: 0001-SV-65448-Compare-va

Re: Conditional append operator (was: Re: New conditional assignment facility)

On Sun, Feb 4, 2024 at 12:05 AM Paul Smith wrote: > > On Sat, 2024-02-03 at 17:45 -0500, Paul Smith wrote: > > Here's how I think the "append changes the type of the variable" > > option works: > ... > > Sorry for the possible confusion. > I feel these proposals are 1) not obvious in how they wor

Re: New conditional assignment facility

On Mon, Jan 22, 2024 at 4:59 PM Martin Dorey wrote: > > Why is that? > > > I imagine because that's how, to my surprise, it is today: > > martind@stormy:~/tmp/make-conditional-assignment-2024-01-22$ cat Makefile > A := 42 > A += $(shell hello) > martind@stormy:~/tmp/make-conditional-assignment-202

Re: New conditional assignment facility

On Mon, Jan 22, 2024 at 2:16 PM Paul Smith wrote: > > If the only goal was to allow +:= create a simple variable, then can > > we do the following? > > "If no variable with this name exists, then +:= creates a simple > > variable, and +:::= creates an immediately-expanded-and-escaped > > variable.

[bug #65019] Let function segfaults when foreach return empty list

Follow-up Comment #4, bug#65019 (group make): Thanks for applying! If I'm not mistaken, I had put a reference in the subject and _git am_ would have included it in the commit message. ___ Reply to this item at:

Re: Bug with $(info xxx) in 4.2.1

On Fri, Dec 8, 2023 at 7:38 PM Paul Smith wrote: > > In make it's fine to have a make line indented with a TAB, that is not > part of a recipe. If a line appears outside of the context of a rule, > then leading whitespace is ignored. There is a section in the documentation called "How Makefiles

[bug #65019] Let function segfaults when foreach return empty list

Follow-up Comment #2, bug#65019 (group make): The attached patch should fix the issue and prevent regressions. (file #55442) ___ Additional Item Attachment: File name: SV-65019-Fix-let-segfault-on-value-with-trailing-whi.patch Size:1 KB

[bug #65019] Let function segfaults when foreach return empty list

Follow-up Comment #1, bug#65019 (group make): You are right! An even shorter way to reproduce the segfault is with $(let a b, ,) Having more than one variable is needed to trigger the bug. Without the whitespace in the value list, the bug also does not trigger. I believe the following will fix

[bug #45799] handle local variables in $(call )

Follow-up Comment #1, bug #45799 (project make): The recently released GNU Make 4.4 has the $(let ...) function, which provides local variables. The current feature request is thus taken care of. ___ Reply to this item at:

[bug #3656] .MUTEX directive

Follow-up Comment #4, bug #3656 (project make): In the recently released GNU Make 4.4, .NOTPARALLEL accepts prerequisites, thus this feature request is effectively satisfied! ___ Reply to this item at:

Re: [PATCH] Fix nonzero detection in integer parsing

On Mon, Dec 20, 2021 at 8:24 PM Jouke Witteveen wrote: > > * src/function.c (parse_textint): Fix nonzero detection. > * tests/scripts/functions/intcmp: Extend test coverage. > --- > > The `*p++ == '0'` test should have been `*p++ != '0'` and did not need &

[PATCH] Fix nonzero detection in integer parsing

* src/function.c (parse_textint): Fix nonzero detection. * tests/scripts/functions/intcmp: Extend test coverage. --- The `*p++ == '0'` test should have been `*p++ != '0'` and did not need to be repeated for every digit anyway. By pure luck, all numbers used in tests included a digit '0', so this

Re: Compilation error with GCC

I believe what you are seeing is reported here: https://savannah.gnu.org/bugs/?60798 The patches "file #52422" and "file #52428" should resolve your issues. Regards, - Jouke On Sun, Dec 19, 2021 at 7:55 PM Mohammad Akhlaghi wrote: > > So sorry, there was a typo in my last mail: > > As the previ

[bug #60798] Make does not compile with GCC 11.1.0

Additional Item Attachment, bug #60798 (project make): File name: SV-60798-Rework-to-silence-GCC11-warning.patch Size:3 KB ___ Reply to

[bug #60798] Make does not compile with GCC 11.1.0

Follow-up Comment #4, bug #60798 (project make): As a sort of exercise, I got rid of the final warning too. This required some moving code around and I duplicated the `strchr` call and the `p[-1] != '\\'` test. Let me know if these changes make any sense. While at it, I also added an update to th

[bug #60798] Make does not compile with GCC 11.1.0

Follow-up Comment #3, bug #60798 (project make): I expanded the patch a bit to also silence a _maybe-uninitialized_ error. With GCC11, there is now only one warning remaining, which is the _return-local-addr_ warning in src/read.c:2534 (find_percent_cached). The code is correct, but GCC fails to

Re: [PATCH] doc: note that $(wildcard) is implemented in terms of glob(3)

On Fri, Dec 3, 2021 at 3:19 PM Ævar Arnfjörð Bjarmason wrote: > > The motivation for this patch is that I've seen code like this in the > wild: > > FILES = $(sort $(wildcard t*.sh)) > > I thought that it would be documented that that sort of thing was > redundant, but I didn't find any mention

Re: [bug #60798] Make does not compile with GCC 11.1.0

On Fri, Dec 3, 2021 at 1:26 PM Edward Welbourne wrote: > > Jouke Witteveen (3 December 2021 13:22) wrote: > > The next warning I get (GCC11) is a _return-local-addr_ warning in > > src/read.c:2534 (find_percent_cached). Maybe GCC doesn't recognize alloca > > a

[bug #60798] Make does not compile with GCC 11.1.0

Follow-up Comment #2, bug #60798 (project make): I couldn't find any signs of GCC becoming clever enough to detect why this code is correct. Minor code changes can silence the _stringop-overflow_ warnings. The next warning I get (GCC11) is a _return-local-addr_ warning in src/read.c:2534 (find_pe

[PATCH] * doc/make.texi (Errors): Document integer width

--- There was some talk of supporting arbitrarily large integers. This was mostly an academic discussion, since the currently supported range (64 bits) should cover all use cases. On Wed, Dec 1, 2021 at 8:49 PM Paul Smith wrote: > > allowing practicality to drive simplification in code turns sof

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

On Sun, Nov 28, 2021 at 3:20 PM Paul Smith wrote: > > On Sun, 2021-11-28 at 14:57 +0100, Jouke Witteveen wrote: > > > Since the two arguments are equal, it doesn't matter which of LHS > > > or RHS we return. > > > > They could differ for instance whe

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

On Sun, Nov 28, 2021 at 3:33 PM Paul Smith wrote: > > On Sun, 2021-11-28 at 08:24 +0100, Jouke Witteveen wrote: > > On the user side, strcmp could now probably be defined something like > > $(and $(intcmp $(words $1),$(words $2)),$(findstring x $1 x,x $2 x)) > > I don&#x

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

On Sun, Nov 28, 2021 at 2:45 PM Paul Smith wrote: > > On Sun, 2021-11-28 at 08:24 +0100, Jouke Witteveen wrote: > > Thanks for sending this message, I would have otherwise prepared and > > sent an updated patch series today. My plan was to expand to RHS in > > the two-argu

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

On Sun, Nov 28, 2021 at 5:02 AM Paul Smith wrote: > > On Mon, 2021-11-15 at 20:49 +0100, Jouke Witteveen wrote: > > It may be obscure, but how about we implement this as well? Sure, the > > two-argument form of $(compare) will be a little inconsistent, but it > > may be us

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

On Tue, Nov 16, 2021 at 10:28 AM Edward Welbourne wrote: > > On Sun, Nov 14, 2021 at 8:42 PM Paul Smith wrote: > > It's even possible to allow $(compare ,) with no other > > arguments and say that if they are equal then it expands to the value, > > else it expands to the empty string, to give a v

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

On Sun, Nov 14, 2021 at 8:42 PM Paul Smith wrote: > > On Wed, 2021-11-10 at 18:19 +0100, Jouke Witteveen wrote: > > On Mon, Nov 8, 2021 at 4:08 PM Paul Smith wrote: > > > > > On Fri, 2021-07-16 at 14:04 +0200, Jouke Witteveen wrote: > > > > $(compare &

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: > > +@item $(compare > > @var{lhs},@var{rhs},@var{lt-part}[,@var{eq-part}[,@var{gt-part}]]) > > Let me ask this: would it be better to use a fo

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

On Mon, Sep 13, 2021 at 8:39 PM Jouke Witteveen wrote: > > On Fri, Jul 16, 2021 at 2:04 PM Jouke Witteveen wrote: > > > > Numbers can come from $(words ...), automatic variables such as > > $(MAKELEVEL), from environment variables, or from shell output such as > > t

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

On Fri, Jul 16, 2021 at 2:04 PM Jouke Witteveen wrote: > > Numbers can come from $(words ...), automatic variables such as > $(MAKELEVEL), from environment variables, or from shell output such as > through $(shell expr ...). The $(compare ...) function allows > conditional evalua

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

ests/scripts/functions/compare diff --git a/NEWS b/NEWS index 5356260..6a3a744 100644 --- a/NEWS +++ b/NEWS @@ -40,6 +40,10 @@ https://sv.gnu.org/bugs/index.php?group=make&report_id=111&fix_release_id=109&se user-defined function and they will not impact global variable assign

[PATCH 2/3] Use strtol instead of atoi

strtol is part of C89 and a fallback is provided by gnulib * src/function.c (func_word, func_wordlist): Use strtol instead of atoi * test/scripts/functions/word: Add out-of-range verification testing --- bootstrap.conf | 1 + src/function.c | 51 ++

[PATCH 1/3] * src/makeint.h: Removed unused atol declaration

--- src/makeint.h | 1 - 1 file changed, 1 deletion(-) diff --git a/src/makeint.h b/src/makeint.h index fcfb7bd..ca6d49d 100644 --- a/src/makeint.h +++ b/src/makeint.h @@ -631,7 +631,6 @@ void spin (const char* suffix); #if !defined (__GNU_LIBRARY__) && !defined (POSIX) && !defined (_POSIX_VE

Re: [PATCH] More correctly describe the scope of variables

On Fri, Jan 29, 2021 at 8:37 AM Jouke Witteveen wrote: > On Fri, Dec 25, 2020 at 7:00 PM Jouke Witteveen wrote: > > > > * NEWS: Use "local" instead of the incorrect "lexically-scoped". > > * doc/make.texi: Refer to let/foreach variables as local variabl

Re: [PATCH] More correctly describe the scope of variables

On Fri, Dec 25, 2020 at 7:00 PM Jouke Witteveen wrote: > > * NEWS: Use "local" instead of the incorrect "lexically-scoped". > * doc/make.texi: Refer to let/foreach variables as local variables. > --- > This is an erratum on the addition of $(let ...). During an

Re: [PATCH] More correctly describe the scope of variables

gards, - Jouke > > On Fri, Dec 25, 2020 at 10:00 AM Jouke Witteveen > wrote: >> >> * NEWS: Use "local" instead of the incorrect "lexically-scoped". >> * doc/make.texi: Refer to let/foreach variables as local variables. >> --- >> This i

[PATCH] More correctly describe the scope of variables

a lexically-scoped - set of variables: values can be assigned to these variables from within the + This function allows user-defined functions to define a set of local + variables: values can be assigned to these variables from within the user-defined function and they will not impact global var

[PATCH 1/2 V2] [SV 51286] Support for lexically scoped variables

* src/function.c: Introduce the 'let' built-in function * tests/scripts/functions/let: Tests for the 'let' built-in function --- This replaces: > [PATCH 1/2] * src/function.c: Introduce the 'let' built-in function and goes together with: > [PATCH 2/2 V2] * doc/make.texi: Document the let function

Re: [PATCH 1/2] * src/function.c: Introduce the 'let' built-in function

On Fri, Oct 9, 2020 at 4:36 PM Jouke Witteveen wrote: > > --- > This was sent before at the end of last year. Meanwhile, the copyright of my > contributions is assigned to the FSF, so I picked this up again and added some > documentation (next patch). > > The previous discus

[PATCH 2/2 V2] * doc/make.texi: Document the let function

--- Thanks to Martin Dorey for spotting a typo in the first version of this patch. I fixed a few others typos too in this revision. This revision is sent just so that the previous version does not get applied accidentally. There may still be parts that could be improved. The first patch in this

[PATCH 2/2] * doc/make.text: Document the let function

--- I think this covers the let function, but comments/suggestions are welcome in case I missed something. Regards, - Jouke doc/make.texi | 87 --- 1 file changed, 75 insertions(+), 12 deletions(-) diff --git a/doc/make.texi b/doc/make.texi index

[PATCH 1/2] * src/function.c: Introduce the 'let' built-in function

--- This was sent before at the end of last year. Meanwhile, the copyright of my contributions is assigned to the FSF, so I picked this up again and added some documentation (next patch). The previous discussion was titled "[RFC] Scoped variables, supercharged". src/function.c | 51 +

Re: [PATCH 2/2] compare function

On Tue, Jun 9, 2020 at 10:53 AM Edward Welbourne wrote: > > Jouke Witteveen (8 June 2020 22:20) > > It differs from his original proposal in that it behaves differently > > when given 4 or 5 arguments. In short, it's signature is > > > > $(compare

[PATCH 1/2] Use strtol instead of atoi

strtol is part of C89 and a fallback is provided by gnulib * src/function.c (func_word, func_wordlist): Use strtol instead of atoi * test/scripts/functions/word: Add out-of-range verification testing --- Here is a proposal to start a more thorough support of numerical values. While earlier discus

[PATCH 2/2] compare function

This is an implementation of a $(compare) function as proposed by Edward Welbourne. It differs from his original proposal in that it behaves differently when given 4 or 5 arguments. In short, it's signature is $(compare lhs,rhs,less-than[,greater-or-equal]) $(compare lhs,rhs,less-than,equal,gr

Re: math expressions (was: Re: Tail call elimination)

On Wed, May 27, 2020 at 8:47 PM Pete Dietl wrote: > > A few questions. > > Technically, the C standard allows for machines which don't use 2's > complement. > So should we consider our LONG_MIN to be -2^63 + 1? > > Also, signed arithmetic overflow is undefined behavior, so should we also > indica

Re: Tail call elimination

On Mon, May 18, 2020 at 8:50 PM Paul Smith wrote: > > On Mon, 2020-05-11 at 16:32 -0500, Pete Dietl wrote: > > I would like to know your thoughts about adding something like $(expr > > ) to evaluate integer expressions and comparisons. > > I have no problem with some basic math facilities. We alr

Re: Tail call elimination

On Mon, May 11, 2020 at 11:33 PM Pete Dietl wrote: > > Indeed I understand these concerns. > So the consensus seems to be that I may go ahead and attempt to implement > this. > > Other than the (let) and tail call optimization, I would like to know your > thoughts about > adding something like $

Re: Let construct

Hi Pete, A month ago, I got in touch with Paul Smith about some paperwork needed for assigning copyright to the FSF. I did not hear back from him since and assume he is busy with other things at the moment. Since Make is quite old, I figured there is no rush. Probably the most important thing for

[bug #51974] call on multiline (define/endef) behavior not well-documented

Follow-up Comment #7, bug #51974 (project make): Either the 'new' documentation is not entirely correct, or there is a bug in the current expansion logic (or I am misunderstanding something). The documentation states: 4. Expand elements of the line which appear in an immediate expansion con

[bug #51286] Support for additional local make variables

Follow-up Comment #3, bug #51286 (project make): > Dit I? Wow, indeed, my memory is quite far off. Sorry! I was thinking of an exchange regarding a request for renaming by thutt. Your only expressed concern was that the behavior of let bindings might not be clear to people not familiar with lang

[bug #51286] Support for additional local make variables

Follow-up Comment #1, bug #51286 (project make): If the value you are trying to assign to a variable is guaranteed to contain no spaces, you could use $(foreach var,,<...>) but that is a bit of a hack of course. More complete lexical scoping was proposed on the mailing list (https://lists.gnu.o

Re: [RFC] Scoped variables, supercharged

On Thu, Dec 26, 2019 at 2:03 PM Jouke Witteveen wrote: > I would like make to have scoped variables. Here, I will propose an > implementation of them. This implementation is currently without tests and > documentation. Hopefully, the proposal is acceptable and I can add the &g

Re: [RFC] Scoped variables, supercharged

On Fri, Dec 27, 2019 at 4:29 PM wrote: > > Jouke Witteveen writes: > > On Thu, Dec 26, 2019 at 10:52 PM Paul Smith wrote: > > > > > > > > > I believe thutt is thinking of creating new scopes in makefiles > themselves, > > > not wit

Re: [RFC] Scoped variables, supercharged

On Thu, Dec 26, 2019 at 10:52 PM Paul Smith wrote: > > On Thu, 2019-12-26 at 21:24 +0100, Jouke Witteveen wrote: > > > Your proposal has the potential to create variables that would have > > > scope local to a single invocation of a user-defined function, but it

Re: [RFC] Scoped variables, supercharged

On Thu, Dec 26, 2019 at 6:13 PM wrote: > Jouke Witteveen writes: > > I would like make to have scoped variables. Here, I will propose an > > implementation of them. This implementation is currently without tests and > > documentation. Hopefully, the proposal is accepta

[RFC] Scoped variables, supercharged

Hi, I would like make to have scoped variables. Here, I will propose an implementation of them. This implementation is currently without tests and documentation. Hopefully, the proposal is acceptable and I can add the tests and documentation. Consider a situation in which we have macros F and G,

Re: [PATCH v2 2/3] [SV 54161] Fix second expansion of $*

On Wed, Dec 18, 2019 at 4:19 PM Paul Smith wrote: > > On Wed, 2019-12-18 at 16:02 +0100, Jouke Witteveen wrote: > > Your se_implicit test case got left out of your commit. I guess this > > was unintentional. > > I'm not sure what you mean? It's there...? My m

Re: [PATCH v2 2/3] [SV 54161] Fix second expansion of $*

On Wed, Dec 18, 2019 at 3:11 PM Paul Smith wrote: > I applied your changes although updates were needed. > > For the future, please note that (a) changes should contain updates to the > regression tests to show the error and ensure the fix works, (b) commit > messages need to be formatted properly

Re: [PATCH v2 2/3] [SV 54161] Fix second expansion of $*

On Sat, Oct 26, 2019 at 12:24 PM Jouke Witteveen wrote: > > Make sure the second expansion of $* in the prerequisites matches that of > $* in the recipe. This means that if we would add the dir of the stem to > the prerequisites, we should replace % by $(*F) in the first expansion.

Re: [PATCH v2 3/3] Oddities in dealing with the path of a stem

On 10/26/19, Jouke Witteveen wrote: > Make the code match the comments. > --- Note that memrchr is a GNU extension, available since glibc 2.1.91 (19 years old). If this particular patch is accepted, we might want to drop the glibc version check in lib/glob.c. This patch does fix a bug

[PATCH v2 2/3] [SV 54161] Fix second expansion of $*

Make sure the second expansion of $* in the prerequisites matches that of $* in the recipe. This means that if we would add the dir of the stem to the prerequisites, we should replace % by $(*F) in the first expansion. Otherwise, we replace it to $*, but make sure that the value of $* used for exp

[PATCH v2 3/3] Oddities in dealing with the path of a stem

Make the code match the comments. --- src/implicit.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/src/implicit.c b/src/implicit.c index e400dc6..f7b8c15 100644 --- a/src/implicit.c +++ b/src/implicit.c @@ -266,7 +266,7 @@ pattern_search (struct file *file, int archiv

[PATCH v2 1/3] Get rid of superfluous variables in stem tracking

--- src/implicit.c | 18 ++ 1 file changed, 6 insertions(+), 12 deletions(-) diff --git a/src/implicit.c b/src/implicit.c index 707eff5..7bdc8ba 100644 --- a/src/implicit.c +++ b/src/implicit.c @@ -443,7 +443,6 @@ pattern_search (struct file *file, int archive, unsigned

Re: [PATCH 2/2] [SV 54161] Fix second expansion of $*

On Sat, Oct 12, 2019 at 3:08 PM Jouke Witteveen wrote: > > On Sat, Oct 12, 2019 at 2:50 PM Paul Smith wrote: > > > > On Sat, 2019-10-12 at 13:11 +0200, Jouke Witteveen wrote: > > > Before, this was only expanded to $(*F) in prerequisites. > > > > Sorry b

Re: [PATCH 2/2] [SV 54161] Fix second expansion of $*

On Sat, Oct 12, 2019 at 2:50 PM Paul Smith wrote: > > On Sat, 2019-10-12 at 13:11 +0200, Jouke Witteveen wrote: > > Before, this was only expanded to $(*F) in prerequisites. > > Sorry but I need more information than this; I can't understand this > change. > > The

[PATCH 1/2] Get rid of superfluous variables in stem tracking

--- Some minor things I came across when working on a fix for [SV 54161], which I'll send next. Sure, the comments say that we should get rid of stem_str, but the reality is that this variable is probably here to stay. Using it for constructing the stem makes the kinship to another place where the

[PATCH 2/2] [SV 54161] Fix second expansion of $*

Before, this was only expanded to $(*F) in prerequisites. --- src/implicit.c | 49 +++-- 1 file changed, 31 insertions(+), 18 deletions(-) diff --git a/src/implicit.c b/src/implicit.c index 7bdc8ba..a887e92 100644 --- a/src/implicit.c +++ b/src/implicit