I just mean writing a test that's portable.  I can try again hard-coding SHELL and restricting the test to only run on Windows, or something like that.

I made a stab at trying to write a test for this but it's too hard, since you have to be sure you're using cmd.exe as the SHELL etc. else the PATH is rewritten.

Okay I'll do that as soon as I can.
Thanks again for your help with the PATH issue.

Best regards.

Indeed, I followed your instructions and I can confirm that the PATH bug is now gone. Thank you kindly.
However, as you suspected, my real application still does not build successfully...

It seems to be an unrelated problem, though. My parallel build is successful when using --output-sync=none, but its stalls indefinitely at various points when using --output-sync=target (which is not the case with Make 4.3)

I should probably open a separate report for this, right?

I downloaded the Make binaries through MSYS2 with:
pacman -S mingw-w64-x86_64-make

Yes, I have a MinGW development environment installed and I can compile C programs.

Eli, Paul, thanks a lot for finding the cause of the problem so quickly!

I am just an end user of make, though, and to be quite honest I don't know how to apply your patch, rebuild make, and test my real-life Makefile.
(I'm really sorry about that)

The minimal Makefile I posted is the result of tracking down the problem I had my real-life Makefile and reducing it to its essence, which makes me pretty confident about the fact that your patch will indeed fix my problem.

That being said, if you're willing to attach your patched .exe, I'll be more than happy to try it right away.

Please let me know if you need any more information,

Thanks again.

Ah, I see.  I spent about 30m last night trying to find this but since I don't really do Windows development I was reduced to printf debugging and couldn't come up with it before I had to go to dinner :).

That was my fault breaking this.  That change makes sense to me (although I'd use the CSTRLEN("PATH=") macro), thanks for finding it Eli!

It would be good if we could add a test for this, since the code is as you say, tricky.  I'll think about how to do it.

Thank you very much for your quick response, Paul. Good to know that you can reproduce this behavior.
I'll switch back to 4.3 for now. Thanks again for your time,
Best regards

Consider the following minimal example:

# ---

# show the content of the environment variable PATH

$(info PATH = $(shell echo %PATH%))


# the first time the makefile is made, we delete the (empty) file we're including below.
# this ensures that its rule gets executed and that the makefile gets remade.

ifeq ($(MAKE_RESTARTS),)
$(shell del missing_at_first.mk)
endif


# the first time the makefile is made, this file doesn't exist, but we have a rule to create it, so we are going to get remade

include missing_at_first.mk


# rule to create an empty file

missing_at_first.mk:
@type nul > missing_at_first.mk

# ---

with make 4.4-2, i get the following result:

PATH = C:\msys64-make-4.4-2\mingw64\bin
PATH = C;\msys64-make-4.4-2\mingw64\bin

please notice how the first colon turned to a semicolon on the second pass.

with make 4.3, i get the expected result:

PATH = C:\msys64-make-4.4-2\mingw64\bin
PATH = C:\msys64-make-4.4-2\mingw64\bin