All:
In tracking down why building parrot with mingw was failing, I discovered
that the culprit was having msys in my PATH even if I wasn't intentionally
trying to use it.
There are 3 interesting things to note:
1. It does not matter what msys is actually called - renaming the directory
to foo has the same effect
2. It does not matter where in the PATH it appears - placing it after mingw
has no effect
3. Changing the PATH has no effect on the configuration cycle - only the
build cycle
Running mingw32-make with the -d (debug) flag on revealed what is going on.
It scans PATH, using an internal routine called find_and_set_shell, looking
for sh.exe which changes path delimiters and shell escapes.
The obvious fix is to do exactly what mingw32-make is doing and warn the
user that the subsequent mingw32-make is going to fail.
This is where the request for comments comes in.
config/init/hints/mswin32.pm is where the mingw specific settings are set
up. The $make variable obtained at this point is nmake, but it would still
be possible to probe $ENV{PATH}, discover if sh.exe exists, and warn the
user.
Configure.pl ends by telling the user the next step. Use $make, which has
changed from nmake to mingw32-make along the way, which is bound to fail.
Perhaps this is the spot where it is appropriate to warn the user.
I don't mind writing the patch but as I have been away for 1.5 years I would
really like to hear the opinions of where is the best way to do it.
Cheers,
Joshua Gatcomb
a.k.a. Limbic~Region
