RFC: Patch for mingw-msys
Joshua Gatcomb
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
Andy Dougherty
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 doug...@lafayette.edu
Joshua Gatcomb
>
> 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?
The patch would be nothing more than a warning. As I said, the PATH
environment has absolutely no effect on the configure process, just the
build process. During the configure process, we can warn the user that the
build process won't work unless they do something about their PATH. In
particular, prevent mingw from using msys and subsequently changing the the
behavior of path delimiters and shell escapes.
I would love to submit a patch to make using msys transparent and "just
work" but after searching the archives, it appears that people working on it
far longer than I have had little to no luck with it and I am just getting
my feet wet again.
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.
It may seem odd to some to put a warning for $make as mingw32-make in a
section of code when $make is actually nmake at that point. Placing it at
the end of Configure.pl may make more sense since it is the last set of
instructions to the user but it appears that a lot of work has gone in to
making it platform neutral.
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.
I don't think it is wrong but perhaps the order of hints/make should
change. I don't know that's why I am asking.
--
> Andy Dougherty doug...@lafayette.edu
Andrew Dougherty
> On 5/26/06, Andy Dougherty <doug...@lafayette.edu> wrote:
> >
> > 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?
>
> The patch would be nothing more than a warning. As I said, the PATH
> environment has absolutely no effect on the configure process, just the
> build process. During the configure process, we can warn the user that
> the build process won't work unless they do something about their PATH.
> In particular, prevent mingw from using msys and subsequently changing
> the the behavior of path delimiters and shell escapes.
Ok, if that's all you want to do, then I think checking PATH in the mingw
hints file and aborting with a message instructing the user to change PATH
is probably the right thing to do. (Yes, I know that changing PATH as
recommended won't affect the Configure process, but the user has got to
fix it before the build process anyway, and putting all that info in
the hints file makes it more likely that the right people will read,
understand, and maintain it in the future.)
> I would love to submit a patch to make using msys transparent and "just
> work" but after searching the archives, it appears that people working on it
> far longer than I have had little to no luck with it and I am just getting
> my feet wet again.
Fair enough. I had misunderstood and thought that, perhaps, simply using
'nmake' instead of 'mingw32-make' might have make it "just work". Oh
well.
--
Andy Dougherty doug...@lafayette.edu