[Python-Dev] Compiling Python 3.2 on Cygwin fails

[Brian Curtin]

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
- it has been up and down for a few months now. If someone else is
interested, go ahead.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110705/526ad820/attachment.html>