[Python-Dev] Compiling Python 3.2 on Cygwin fails (original) (raw)

Brian Curtin brian.curtin at gmail.com
Tue Jul 5 22:00:24 CEST 2011

On Tue, Jul 5, 2011 at 14:41, Dan Stromberg <drsalists at gmail.com> wrote:

On Tue, Jul 5, 2011 at 12:18 PM, Brian Curtin <brian.curtin at gmail.com>wrote:

On Tue, Jul 5, 2011 at 14:12, Dan Stromberg <drsalists at gmail.com> wrote:

On Tue, Jul 5, 2011 at 7:25 AM, David Robinow <drobinow at gmail.com>wrote:

Cygwin is not really a supported platform. ... [Ultimately somebody with an interest in cygwin will need to get active in python development. I've been meaning to do this but life gets in the way.] I was bitten by the lack of Cygwin support in 3.2 as well. IMO, python-dev needs continuous integration on a build farm that includes representative platforms. Most of the machines in the farm could be virtualboxes. I don't think the problem is so much that the right people haven't gotten involved, as that the currently-involved people don't know when they're breaking something for someone else due to the lack of continuous integration. We've had that for some time now: http://www.python.org/dev/buildbot/ Good to know. Apologies for my incorrect assumption. Where do the e-mail notifications of build and/or test failures go?

There might be an RSS feed or something, but I don't think there's any email notification. #python-dev on IRC receives live failure info. Other than that, you'd just have to look at one of the views of the fleet to see which build slaves are failing.

Shouldn't Cygwin be represented here? I don't see it in the list of builds.

Probably, but it isn't represented because no one contributed a build slave for it. I know some of the other Windows build slave operators use Cygwin to some degree, but I'm not sure if anyone has looked into actually setting up a build slave for it.

Some shops have a policy that nothing gets merged into trunk unless it's

passing critical automated tests... Would that work here?

We don't make much use of branching, but that would work if we did. If no one is actively contributing work on the Cygwin build then I don't see us holding up work in order to figure out any Cygwin-specific issues.

There are several issues on the bug tracker about cygwin build issues, but

to my knowledge, none of them have included successful patches.

I think you'll find that most people using Cygwin would rather be working on some other OS, but are forced to use Windows for policy reasons. It's remains a rather significant need in many cases.

I don't disagree with that, but if there's no one contributing Cygwin patches then it will probably just die off and we'll have situations like the current one where it doesn't build. A great majority of the contributing developers are on UNIX-based systems with no access to Windows. A small handful, myself included, are Windows users, but I don't think any of us use Cygwin (I don't).

Native Windows builds do appear to be represented. Is there any reason not

to set up a buildbot for Cygwin on the same (virtual?) hardware?

Besides the time and effort needed to set it up and occasionally look over it, no. We'd have to have a successfully compiling Cygwin build before we think about adding a build slave for it.

I wouldn't be opposed to hosting this myself, but I need to steal some time and get my Windows 2008 build slave back to some form of a functional system

More information about the Python-Dev mailing list