Re: [Monotone-devel] MinGW32 buildbot ready

[Stephen Leake]

Stephen Leake <address@hidden> writes:

> I'm using a Cygwin installation of Python to run buildbot; it had some
> problems installing, but seems to run the buildbot code up to the
> point where it tries to connect to the central server.

Now I can connect to the buildbot master, but I've run into a problem.

One of the steps in the build process is to run 'autoreconf -i'.

This works properly if run from a "pure" MinGW shell; no cygwin in the
path, running the MinGW perl, etc.

However, since I'm running the Cygwin python, cygwin is in the path,
and it just gets confused, even though MinGW is in the path first.
That's because all the auto* scripts have #!/bin/perl in them, and
that runs the Cygwin perl.

I tried running the native Win32 python, and that's even worse; it
spawns a new copy of cmd.exe for _every_ command, so MinGW is never in
the path.

The core python code has a "platformtype" variable that is either
"posix" or "win32"; if "win32", it runs "$COMSPEC /c <command>" for
every command. I tried setting COMSPEC to MinGW/bin/sh, but the /c
gets in the way, and it is hard-coded.

One way to fix this (probably the "right way" in the long run) is to
hack on the buildbot and core Python code to add a new platform type
"mingw". But that's a lot of work. I can't just use "posix" (even if I
could figure out how), because the low-level spawn would then be
wrong, unless it's the Cygwin python.

Can the buildbot master be customized to run a different command for
the 'autoreconf -i' step for this particular build slave? I could
write a shell script that spawns a MinGW shell to run it properly.

The configure step also needs to be specialized. All the other build
steps run nicely in the mixed MinGW/cygwin environment.

--
-- Stephe