`make` shouldn't be an alias for `mingw32-make`

[HolyBlackCat]

Description

Currently, when installing mingw, you copy mingw32-make.exe to make.exe.

I suggest that this shouldn't be done.

Those are two different flavors of Make with different bugs/quirks, and non-trivial makefiles written for one will not work with another. When I see make.exe on Windows, my expectation is that it's Cygwin-based, which is e.g. what MSYS2 does (they have both Cygwin-based make.exe and MinGW-based mingw32-make.exe).

We just spent some time debugging a misbehaving makefile, only to realize that we accidentally ran it using the preinstalled make.exe (which is mingw32-make.exe in disguise) rather than MSYS2 make.exe.

Here's an example of a mingw32-make-specific quirk, it's the one we ran into. The annoying part is that I knew about this, but figured that it couldn't be affecting us since we weren't invoking mingw32-make explicitly.

Platforms affected

• Azure DevOps
• GitHub Actions - Standard Runners
• GitHub Actions - Larger Runners

Runner images affected

• Ubuntu 22.04
• Ubuntu 24.04
• Ubuntu Slim
• macOS 14
• macOS 14 Arm64
• macOS 15
• macOS 15 Arm64
• macOS 26
• macOS 26 Arm64
• Windows Server 2022
• Windows Server 2025
• Windows Server 2025 with Visual Studio 2026

Image version and build link

20260428.139.2

Is it regression?

I think not

Expected behavior

make.exe either shouldn't be in the PATH at all, or should be a proper cygwin-based make.exe

Actual behavior

make.exe is a copy of mingw32-make.exe

Repro steps

[v-sergei-pyshnoi]

@HolyBlackCat Thanks for highlighting this! The reason make.exe points to MinGW make is to support workflows that invoke make.exe directly. Since the image provides a MinGW-based toolchain, exposing mingw32-make.exe as make.exe gives those workflows a conventional make.exe entry point without requiring changes to their build scripts. MSYS make and MinGW make are both GNU Make implementations, so many Makefiles, especially simple or mostly compiler-driven ones, can work with either. At the moment, we do not plan to change this behavior, since replacing the current make.exe with a different implementation or removing it would be a breaking change and could potentially affect existing workflows that rely on the current MinGW-based make.exe behavior. That said, we understand the concern and will keep this feedback in mind for future image/tooling updates.