std.Build.findProgram() is not capable of finding non-.exe programs on Windows

[alexrp]

Since the function unconditionally appends b.graph.host.result.exeFileExt() to each element in names when testing paths, it appears to just be impossible to locate e.g. npm.cmd on Windows.

My first thought here is that it should just be changed to try both with and without exeFileExt(). That way, I can pass .{"npm", "npm.cmd"} and it should just work on Windows/Unix. I can open a PR for that if it's considered an acceptable solution.

[rohlem]

Looking at this again, we already have logic for determining whether a file has an executable suffix in std.process.Child.windowsCreateProcessSupportsExtension,
which is integrated when spawning a child process via spawn -> spawnWindows -> std.process.Child.windowsCreateProcessPathExt.
It seems like this supports further extensions (.bat, .cmd, .com, .exe) and fundamentally doesn't settle on the extended version until it's tried the non-extended one.

We might want to extract that logic and re-use it in the build system instead of doing something subtly different,
though this can be done in a follow-up PR/change to #20337 .
@squeek502 , seems like the extension logic in std.process.Child was written by you, if you want to weigh in on this.

[alexrp]

Unifying this sounds reasonable. Do we have a good place to put that logic?

[squeek502]

We might want to extract that logic and re-use it in the build system

This was my initial thought as well. Note, though, that most of the complexity of that code in std.process.Child is around making it fast, which findProgram might not need to care about as much. The basic idea is pretty simple:

• for each search path:
  • try unsuffixed command name
  • iterate PATHEXT environment variable, split by ; (can filter out any we don't support spawning via std.process.Child, that's what windowsCreateProcessSupportsExtension is for)
    • append the current extension from PATHEXT to the command name and try that

EDIT: To clarify, I think it might make sense to just reimplement a simpler version of the search path logic rather than try to make the std.process.Child implementation re-usable.

[alexrp]

Looking at the std.process.Child code, it seems to only support a small subset of the default values of PATHEXT. Perhaps it would make more sense to just specifically look for the supported extensions, and add a comment to keep it in sync with std.Build.findProgram()?

[alexrp]

Or, actually, I guess we would still want to respect the values in PATHEXT (e.g. if the user has removed .bat from there, we should respect that). So iterate PATHEXT, but duplicate a simplified version of the check for the supported subset of extensions?

[squeek502]

Yeah, it should be possible to simplify filtering PATHEXT since it doesn't have to deal with WTF-16, so it can just use some if/elses with std.ascii.eqlIgnoreCase

(or std.StaticStringMapWithEql(void, std.static_string_map.eqlAsciiIgnoreCase), but StaticStringMap won't actually provide much/any benefit because it's only faster when the keys are of different lengths).