Open Bug 1382940 Opened 7 years ago Updated 2 years ago

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

Categories

(Firefox Build System :: General, enhancement)

enhancement

Tracking

(firefox57 wontfix)

Tracking Status
firefox57 --- wontfix

People

(Reporter: gps, Unassigned)

References

Details

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.
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.
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.
Product: Core → Firefox Build System
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.