1382940 - Check for programs that have both <name> and <name>.exe

Status: NEW

(Firefox Build System :: General, enhancement)

Description

[Gregory Szorc [:gps]]

Bug 1377216 added a check_prog() for 'hg'. On many Windows installs, there exists both a "hg" and "hg.exe". If told to search for "hg" configure will find the "hg" shell script. Upon executing it, we get the "not a windows application" error.

We worked around this by adding both "hg.exe" and "hg" to the program names, preferring hg.exe.

We should solve this issue generically in check_prog() and/or find_program(). We could potentially sniff for a shebang and discard on Windows. We could potentially also call which.whichall() and prefer a .exe variant if it is found. Although it gets wonky in cases where the .exe is in a different directory from the non-exe version.

Comment 1

[Mike Hommey [:glandium]]

The problem is not only about having both <name> and <name>.exe. It's about trying to execute things that are not executables with CreateProcess. A user might legitimately pass in a script as e.g. CCACHE, and that will fail when configure tries to execute it because it's a script. But the fact is that if configure didn't try to execute for some reason, the build system might just have worked with it. (I didn't pick CCACHE randomly, btw, I actually tried exactly that last week for other reasons).

The worst cases are when we move checks from old-configure, where such a value would have worked.

So, as I said on irc, IMHO, we should, after getting a "not a win32 application" exception, check if the executable starts with a shebang, and retry through the shell. Or maybe check preemptively.

Comment 2

[Gregory Szorc [:gps]]

It seems like we may want to add a "require_native" and/or "allow_script" argument to find programs. Something to help distinguish whether it is acceptable to find an executable that works inside or outside a UNIX-like environment on Windows.