`Make` not working when called from Notepad++ script since `2.6.0`, worked on all previous versions

[raysan5]

When trying to call mingw32-make from a Notepad++ script, it does not work. This happens since release 2.6.0, it worked on all previous releases.

Command executed from Notepad++ script, on w64devkit 2.6.0 and beyond:

mingw32-make  PLATFORM=PLATFORM_WEB -B
Process started (PID=8164) >>>
make rfxgen
c:/raylib/w64devkit/bin/sh: line 0: make: not found
make: *** [Makefile:323: all] Error 127
<<< Process finished (PID=8164). (Exit code 2)

When using 2.5.0 and previous versions, it worked:

mingw32-make  PLATFORM=PLATFORM_WEB -B
Process started (PID=9668) >>>
make rfxgen
make[1]: Entering directory 'C:/GitHub/rfxgen/src'
emcc -c rfxgen.c -o rfxgen.o -Wall -D_DEFAULT_SOURCE -Wno-missing-braces -Wno-unused-value -Wno-pointer-sign  -std=gnu99 -O3 -I. -Iexternal -IC:/GitHub/raylib/src -DPLATFORM_WEB
emcc -o ./rfxgen.html  rfxgen.o -Wall -D_DEFAULT_SOURCE -Wno-missing-braces -Wno-unused-value -Wno-pointer-sign  -std=gnu99 -O3 -I. -Iexternal -IC:/GitHub/raylib/src -L. -LC:/GitHub/raylib/src -sUSE_GLFW=3 -sTOTAL_MEMORY=128MB -sSTACK_SIZE=1MB -sFORCE_FILESYSTEM=1 -sMINIFY_HTML=0 -sASYNCIFY -sASYNCIFY_STACK_SIZE=1048576 --shell-file minshell.html C:/GitHub/raylib/src/libraylib.web.a -DPLATFORM_WEB
make[1]: Leaving directory 'C:/GitHub/rfxgen/src'
<<< Process finished (PID=9668). (Exit code 0)

Note that this issue is currently affecting all raylib users that downloaded raylib through the preconfigured windows installer package, right now 8,420 users.

[skeeto]

This is likely due to disabling the "fast" path in 9cbd374. GNU Make embeds a virtual shell for very simple commands. I disabled it because it's buggy and unreliable, especially on Windows, producing different results from real shells in common situations, such as here, but also in interactions with Ccache, motivating that patch. See also #370.

Originally make rfxgen matches the "simple command" pattern and uses the virtual shell. Then the virtual shell looks at this command and sees the command is make and thinks, "Oh, that's me, I'll just do this myself" without looking for or invoking a make program. With the virtual shell disabled, GNU Make sends make rfxgen to a shell, which then looks for make (the semantically-correct behavior even if roundabout and inefficient). Without w64devkit/bin/ on $PATH, this fails.

It might still work with make.exe depending on how it's invoked. If it's invoked such that argv[0] is a path to the EXE (e.g. path\to\make.exe) then $(MAKE) is set to that absolute path and Makefile commands like $(MAKE) rfxgen will usually work. (Note how this fails when the $(MAKE) path contains a space, as Make is generally unequipped to deal with paths with spaces.) The alias does not pass though its argv[0], as it would point to mingw32-make.exe, and argv[0] will always be make in the real GNU Make program when invoked through the alias.

Some points:

1. Do not use mingw32-make in new code. This is a compatibility alias (a mere 3kB in unsigned builds) for ancient scripts designed to operate with the defunct MinGW project (distinct from its successor, Mingw-w64), where the mingw32- prefix was intended to distinguish it as a "native" make (versus Cygwin make in some Frankenstein tooling environment). Just use make; that's the real program.

2. If your Makefile expects cmd.exe as the shell, e.g. it uses del, then it must explicitly request it with SHELL = cmd. Otherwise you leave it up to GNU Make to pick a shell, and it will prefer a POSIX shell if it finds one, e.g. sh.exe in w64dk. Without w64devkit/bin/ in your $PATH you're probably getting cmd.exe by chance, and the build may fail if there's a sh.exe in $PATH, e.g. because it's in a proper w64dk environment.

3. Using w64dk's make without w64dk in $PATH loses some of its core strengths. For example, resorting to cmd.exe's inferior del instead of the rm sitting right there next to make.

[raysan5]

@skeeto Thank you very much for the quick and detailed response. w64devkit/bin was already added to the path; I tried replacing mingw32-make by just make (thanks for that improvement!) I I also tried adding the SHELL=cmd, but it seems it still fails.

Here the full Notepad++ script for completion:

echo > Choose compile options
echo -------------------------------
echo Set desired PLATFORM: DESKTOP, DESKTOP_SDL, WEB, DRM, ANDROID
SET PLATFORM=PLATFORM_WEB
echo
echo > Setup required Environment
echo -------------------------------------
SET RAYLIB_PATH=C:\GitHub\raylib
SET COMPILER_PATH=C:\raylib\w64devkit\bin
ENV_SET PATH=$(COMPILER_PATH)
SET MAKE=make
SET SHELL=cmd
cd $(CURRENT_DIRECTORY)
echo
echo > Clean latest build
echo -----------------------
cmd /c del /F *.o
echo
echo > Execute makefile (generic)
echo -----------------------------
$(MAKE) PLATFORM=$(PLATFORM) -B
echo
echo > Reset Environment
echo --------------------------
ENV_UNSET PATH

Console result (only make call part):

> Execute makefile (generic)
-----------------------------
make PLATFORM=PLATFORM_WEB -B
Process started (PID=10704) >>>
make rfxgen
c:/raylib/w64devkit/bin/sh: line 0: make: not found
make: *** [Makefile:323: all] Error 127
<<< Process finished (PID=10704). (Exit code 2)

Do you know if there is some other way to address it? 🤔

EDIT: It seems Notepad++ does not set the shell, I trieed to be more explicit seting it on the make call but it neither worked:

> Execute makefile (generic)
-----------------------------
make SHELL=cmd PLATFORM=PLATFORM_WEB -B
Process started (PID=6428) >>>
make rfxgen
'make' is not recognized as an internal or external command,
operable program or batch file.
make: *** [Makefile:323: all] Error 1
<<< Process finished (PID=6428). (Exit code 2)

[raysan5]

I kept doing tests and surprisingly, it works if I just remove the PLATFORM=$(PLATFORM) argument, with no need to even define SHELL:

echo > Choose compile options
echo -------------------------------
echo Set desired PLATFORM: DESKTOP, DESKTOP_SDL, WEB, DRM, ANDROID
SET PLATFORM=PLATFORM_WEB
echo
echo > Setup required Environment
echo -------------------------------------
SET RAYLIB_PATH=C:\GitHub\raylib
SET COMPILER_PATH=C:/raylib/w64devkit/bin
ENV_SET PATH=$(COMPILER_PATH)
SET MAKE=make
cd $(CURRENT_DIRECTORY)
echo
echo > Clean latest build
echo -----------------------
cmd /c del /F *.o
echo
echo > Execute makefile (generic)
echo -----------------------------
$(MAKE) -B
echo
echo > Reset Environment
echo --------------------------
ENV_UNSET PATH

It seems there could be some issue with parameter parsing? Any variable I try to pass to make fails, even defining them directly:

$(MAKE) -B PLATFORM=PLATFORM_WEB

[Peter0x44]

@raysan5 you can just copy the make.exe from the older w64devkit and that should fix it for now.

[skeeto]

w64devkit/bin was already added to the path

Hmm, yet the shell cannot find make. That's why I assumed it wasn't on $PATH. Though on revisit, I notice in your original report make found and used sh, and then sh couldn't find make right next to it. In your followup example with SHELL=cmd we see from the error message that cmd is now the shell, still unable to find make.

Taking a look at what I think is the Makefile in question:
https://github.com/raysan5/rfxgen/blob/master/src/Makefile

I see this suspicious line:

ifeq ($(PLATFORM),PLATFORM_WEB)
    ...
    export PATH         = $(EMSDK_PATH);$(EMSCRIPTEN_PATH);$(CLANG_PATH);$(NODE_PATH);$(PYTHON_PATH):$$(PATH)
endif

Particularly: :$$(PATH). Colon separator instead of semicolon, which will damage the first path element (w64devkit/bin?), making all those programs disappear. Is the double $$ intended, too?

[raysan5]

@skeeto Very good catch! That Makefile line was written +10 years ago and I can't remember why :$$(PATH) was appended that way (instead of just using ;$(PATH)). On a quick google search I got:

(...)we need to use $$ to reference the shell variable, so that make doesn’t expand it in the read-in phase, and the shell expands it in the target-update phase.

But definitely, the issue was related to that line. I just changed it to ;$(PATH), but then I got:

> Execute makefile (generic)
-----------------------------
make PLATFORM=PLATFORM_WEB -B
Process started (PID=6976) >>>
make rfxgen
Makefile:99: *** Recursive variable 'PATH' references itself (eventually).  Stop.
<<< Process finished (PID=6976). (Exit code 2)

Asking ChatGPT about that issue, it gave me the answer:

That error happens because this line:

 > export PATH = ... $(PATH)

creates a recursively-expanded variable that references itself.

Use := instead of = so Make expands it immediately:

 > export PATH := $(EMSDK_PATH);$(EMSCRIPTEN_PATH);$(CLANG_PATH);$(NODE_PATH);$(PYTHON_PATH);$(PATH)

= → recursive expansion
:= → immediate expansion

With :=, GNU Make uses the current PATH value and avoids the infinite recursion.

And that change effectively solved the issue and it compiles again. I'll test it with VSCode and other platform.