Re: [PATCH] Fix type errors in win32.

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Sun, 28 Nov 2021 15:19:15 -0500 > > On Mon, 2021-10-25 at 15:32 +0300, Eli Zaretskii wrote: > > the default C runtime used by Make doesn't support %llu, at least not > > on Windows versions older than Windows 10. > > Hrm, I just added a new use o

[bug #55242] Included Makefile not found, no rule to build it but make does not fail

Follow-up Comment #4, bug #55242 (project make): i agree that the makefile in question is incorrect. i don't think the patch should be applied. i should not have provided the patch to begin with. i'd just gave the 'a.mk: b' rule a proper recipe which builds 'a.mk', rather than an empty recipe. Wi

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

Follow-up Comment #22, bug #48643 (project make): > If I add a note when we start the compatibility check, it shows up here (obviously we'd pick a more informative note if we added this): ... > I guess it's appropriate here but it seemed odd to me. i also think, it is appropriate here. Does the m

[bug #61409] The code used to create sub-processes on Windows triggers the spawnve() issue

Follow-up Comment #6, bug #61409 (project make): Now I have a slightly better understanding of the problem, although I had no time to experiment anything yet. The real problem is in Microsoft UCRT, which has a bug in the code managing the environment. Unfortunately, even if Microsoft will fix th

[bug #61042] Enhance implicit rule search logging

Follow-up Comment #12, bug #61042 (project make): > I used it because I wanted to mark that data member as being "private" in the sense that it shouldn't be used directly by other parts of the code; instead the get_rule_defn() function should always be called to retrieve that value. Good to know.

[bug #55242] Included Makefile not found, no rule to build it but make does not fail

Follow-up Comment #3, bug #55242 (project make): I tried these patches (some updates were needed as remake.c has changed slightly). They do fix the original issue but I thought of a new test to add: # Allow included files to be updated as side-effects of prereqs. Here a.mk # already exists, but

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

Follow-up Comment #21, bug #48643 (project make): I thought about this but adding such a note caused it to turn up in somewhat unusual places. For example in this test: all: hello.tsk %.tsk: %.o; $(info hello.tsk) %.o: %.c; $(info hello.c) %.o: %.f %.tsk; $(info hello.f) we expect to get this o

[bug #61042] Enhance implicit rule search logging

Follow-up Comment #11, bug #61042 (project make): I used it because I wanted to mark that data member as being "private" in the sense that it shouldn't be used directly by other parts of the code; instead the get_rule_defn() function should always be called to retrieve that value. If we were usin

[bug #61042] Enhance implicit rule search logging

Follow-up Comment #10, bug #61042 (project make): Thank you, Paul. Does the leading underscore in rule->_defn has a special meaning, follow gnu make convention or similar? ___ Reply to this item at:

[bug #61409] The code used to create sub-processes on Windows triggers the spawnve() issue

Follow-up Comment #5, bug #61409 (project make): Reading the busybox issue thread here https://github.com/rmyorston/busybox-w32/issues/234 it _appears_ that the problem really is not related to GNU make, although I can't understand why the failure is only seen if the program is invoked from GNU ma

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

Follow-up Comment #20, bug #48643 (project make): Thank you, Paul. The user may not realize that their makefile relies on compatibility search and the related performance penalty. Do you think it is appropriate to print a message when make begins compatibility search to let the user know? __

Re: [PATCH] Fix type errors in win32.

On Mon, 2021-10-25 at 15:32 +0300, Eli Zaretskii wrote: > the default C runtime used by Make doesn't support %llu, at least not > on Windows versions older than Windows 10. Hrm, I just added a new use of sprintf() with %lld into GNU make, to format a long long variable. It worked for me in my tri

[bug #61409] The code used to create sub-processes on Windows triggers the spawnve() issue

Follow-up Comment #4, bug #61409 (project make): If Make invokes other programs, and those programs have problems because the use UCRT, how is that a problem of Make? What I meant by my comment about MinGW was that as long as Make doesn't use the 'spawnve' implementation from UCRT, Make itself is

[bug #61409] The code used to create sub-processes on Windows triggers the spawnve() issue

Follow-up Comment #3, bug #61409 (project make): I agree that GNU make shouldn't / can't fix a problem in the MS runtime. The question is, whether there's a way GNU make could work around or avoid the problem (and how annoying that would be). I'm not sure I understand the comment that as long as

[bug #61409] The code used to create sub-processes on Windows triggers the spawnve() issue

Follow-up Comment #2, bug #61409 (project make): AFAIU, this problem only happens when using the UCRT runtime, which is not what MinGW uses. So, as long as MinGW doesn't use UCRT, this is largely a theoretical problem for GNU Make on Windows. If and when MinGW64 will start using UCRT as its runt

[bug #61409] The code used to create sub-processes on Windows triggers the spawnve() issue

Follow-up Comment #1, bug #61409 (project make): Unfortunately I have no experience in Windows. Someone who has such experience will need to track this down and figure out what's going wrong. I don't know if Eli has time or energy for this or not. ___

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

Update of bug #48643 (project make): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #19: I pushed Dmitry's fix

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

On Sun, 2021-11-28 at 15:49 +0100, Jouke Witteveen wrote: > I fully agree, but was not aware of the robustness of INTSTR_LENGTH. > It felt a bit fragile when I spotted its definition in makeint.h. The C standard defines the largest unsigned long long value as 18446744073709551615, the largest sign

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 when one of them contains a '+'-sign. > > My reason

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't think this is equivalent si

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

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$1x,x$2x)) I don't think this is equivalent since a putative strcmp would also do greater / less than comparison

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

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 when one of them contains a '+'-sign. > My reason for using LHS is that we already have a string for it. I don't

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-argument case if both values

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

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-argument case if both values are equal. I assume you also > updated the documentation wher