On Fri, 26 May 2006, Joshua Gatcomb wrote:

> 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.

I don't know anything about either msys or mingw, so I don't really know 
what to recommend.

I'm afraid I don't understand what a patch would actually try to do.
>From your previous message, it looks like sh.exe is changing the path 
delimiters and shell escapes so that things don't work anymore.  Are you 
trying to patch Configure.pl to handle those changed delimiters and shell 
esacapes?  Or do you have something else in mind?

Also, what's the preliminary setting of $make got to do with it?  You've 
still got to call some sort of make command in the end.

If you're just wondering where '$make' gets set, then config/inter/make.pm 
is where to look -- it seems to prefer mingw32-make over nmake.  Perhaps 
that's wrong.

-- 
    Andy Dougherty              [EMAIL PROTECTED]

Reply via email to