[Python-Dev] Compiling Python 3.2 on Cygwin fails
drsalists at gmail.com
Tue Jul 5 22:10:14 CEST 2011
On Tue, Jul 5, 2011 at 1:00 PM, Brian Curtin <brian.curtin at gmail.com> wrote:
> 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
>>> 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.
Am I correct in assuming that "stable" buildbots are required to be
reasonably functional before a release is tagged?
> Shouldn't Cygwin be represented here? I don't see it in the list of
> 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.
I might suggest that doing so (using branching, keeping trunk stable) might
be of benefit, especially with a DVCS.
> 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).
Is there a python.org resource for setting up mailing lists - say, for a
python-cygwin mailing list?
> 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.
That makes sense.
> 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.
I might contribute some elbow grease if someone could get me VNC access to a
suitable Windows server.
BTW, is there someone available who is familiar with the meanings of the
various shared object-related make symbols? I glanced at them and didn't
find their naming astonishingly clear - seems like something to document,
or... maybe it already is, and I just haven't seen where it is yet.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev