libxcb 1.12 and master (65b298c7ca317d7e4316aa2b9e0499e13047c65c) fails to build with python3. The first issue with python3 was the tabs/spaces inconsistency. Once that was addressed, the build continued to fail with: Traceback (most recent call last): File "./c_client.py", line 3294, in <module> from xcbgen.state import Module File "/opt/local/lib/python3.4/site-packages/xcbgen/state.py", line 7, in <module> from xcbgen import matcher File "/opt/local/lib/python3.4/site-packages/xcbgen/matcher.py", line 12, in <module> from xcbgen.xtypes import * File "/opt/local/lib/python3.4/site-packages/xcbgen/xtypes.py", line 504 print "Explicit start-align for %s: %s\n" % (self, self.required_start_align) ^ Originally reported at https://trac.macports.org/ticket/51514#no3 Full log: https://gist.github.com/cdeil/eac3b160a5b6475eac3b4e0b129e7bb6#file-gistfile1-txt-L393
It's clear from the line in the traceback that that's a print statement, not a print function. For compatibility, XCB would need to use "from __future__ import print_function" and then switch to using print as a function. I'm all for making xcbgen work with Python 3, but for the moment, until that works, could we explicitly use Python 2 to prevent this breakage? The scripts use "/usr/bin/env python". "python" should not refer to Python 3, per PEP 394 (https://www.python.org/dev/peps/pep-0394/), which says "for the time being, all distributions should ensure that python refers to the same target as python2"; however, some distributions (including Arch, and apparently including macports in some configurations) go against that recommendation and knowingly cause breakage. To avoid that, we could use "python2" in the shebang lines. Similarly, in configure.ac, after calling AM_PATH_PYTHON, we should check that $PYTHON_VERSION starts with "2.".
The very next line states: however, end users should be aware that python refers to python3 on at least Arch Linux (that change is what prompted the creation of this PEP), so python should be used in the shebang line only for scripts that are source compatible with both Python 2 and 3. So should we change the shbang to python2 for better compatibility?
Crap, saved too soon... I'd bet there's an autoconf macro out there somewhere to handle finding an appropriate python2 interpreter. On systems where python2 doesn't exist, we'd still want to fallback on python. I see on OS X that /usr/bin/python2.7 and /usr/bin/python exist, but there is no /usr/bin/python2.
(In reply to Jeremy Huddleston Sequoia from comment #2) > So should we change the shbang to python2 for better compatibility? Yes, that's one of the things I'm suggesting. But I'd also suggest that MacPorts should not install Python 3 as "python", in any configuration. > I'd bet there's an autoconf macro out there somewhere to handle finding an appropriate python2 interpreter. We'd need one, yes. It should check for "python2", fall back to "python", and otherwise act like AM_PATH_PYTHON.
(In reply to Josh Triplett from comment #4) > (In reply to Jeremy Huddleston Sequoia from comment #2) > > So should we change the shbang to python2 for better compatibility? > > Yes, that's one of the things I'm suggesting. But I'd also suggest that > MacPorts should not install Python 3 as "python", in any configuration. MacPorts doesn't. Users control that themselves (to their own detriment).
(In reply to Jeremy Huddleston Sequoia from comment #5) > (In reply to Josh Triplett from comment #4) > > (In reply to Jeremy Huddleston Sequoia from comment #2) > > > So should we change the shbang to python2 for better compatibility? > > > > Yes, that's one of the things I'm suggesting. But I'd also suggest that > > MacPorts should not install Python 3 as "python", in any configuration. > > MacPorts doesn't. Users control that themselves (to their own detriment). That's what I meant; thanks for filing https://trac.macports.org/ticket/51572 . (Note, for instance, that Debian's Python packages intentionally do not manage /usr/bin/python via the alternatives mechanism.)
All python-3 failures that I was seeing have been addressed in git already.
Oh, this is actually in xcb-proto, not libxcb.
commit bea5e1c85bdc0950913790364e18228f20395a3d Author: Thomas Klausner <wiz@NetBSD.org> Date: Thu May 19 17:30:05 2016 +0200
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.