[Xcb] Python generator / cairo problems
ewalsh at tycho.nsa.gov
Mon Apr 21 13:41:42 PDT 2008
Ian Osgood wrote:
> On Apr 21, 2008, at 11:17 AM, Ian Osgood wrote:
>> On Apr 21, 2008, at 7:52 AM, Jeremy A. Kolb wrote:
>>> Are you refering to Felix Rabe's email? It looks like he sorted it
>>> On Mon, 21 Apr 2008, Ian Osgood wrote:
>>>> On Apr 19, 2008, at 8:34 PM, Jeremy Kolb wrote:
>>>>> Now that we have the python generator (sweeeeeet)...
>>>> Speaking of which...
>>>> A rant about building the cairo XCB backend was just posted on the
>>>> cairo mailing list. From the logs, it may have to do with the new
>>>> python code generator.
The only part in this mail that had to do with the Python parser was the
part where he got the error "failed to load the xcbgen Python package."
This is because if you use an install location that is not on your
Python path, the c_client.py script in libxcb will not be able to find
the xcbgen libraries installed by xcb/proto. I made the error message
pretty descriptive in this case and put a note in the README file about
how to create a *.pth file to extend the python path.
However, his mail notes that there is a PYTHONPATH environment variable.
I'll commit a change to the build that sets this variable. That will
probably fix this problem entirely.
>> Thanks, I spoke too soon. His HOWTO could use some work, though (all
>> of xorg???).
>> It is claiming Python 2.5 is required. Is it really using 2.5-only
>> features, or could the version requirement be loosened to 2.4 or 2.3?
>> Has anyone tried it on earlier Python versions? Should it advertise a
>> requirement for a specific version of xml.etree.cElementTree? Also,
>> could ElementTree be used if cElementTree is unavailable?
I used a function named rpartition which was labeled as 2.5-only. It
just splits a string on a separator so I'll see if I can find a
replacement for it. That's the only 2.5-ism I'm aware of in the code
itself. However, the documentation for ElementTree and cElementTree says
that they didn't get bundled with the default Python install until 2.5.
ElementTree and cElementTree are basically interchangeable. The code
doesn't use any fringe features so it probably works with any release of
>> (When baked, the XSLT file xcb.xsd should also be deleted, or make it
>> a build option whether to use Python or XSLT.)
xcb.xsd is the schema description which should not be removed.
c-client.xsl is the stylesheet, which can be deleted.
>> (Also, has anyone measured the difference in build speed between the
>> XSLT and Python code generation?)
No, but the current Makefile.am in libxcb/src runs the Python script
twice (once for .c and once for .h) even though it generates both files.
Don't know how to express in the Makefile.am the notion of "this
generates both .c and .h files."
> Also, I thought the Python generator was adding some new constructs
> for the Xinput or XSELinux protocol descriptions, but I haven't seen
> any recent changes to xcb/proto/doc/xml-xcb.txt
Haven't done this yet. XSELinux doesn't need any new constructs. XInput
does and I'm aware of its semantics (I described them in a previous mail
to the XCB list). But my primary reason for writing this is so I can
provide XCB Python bindings to an SELinux project that needs them. I had
the "xpyb" repo created last week to hold this work.
Eamon Walsh <ewalsh at tycho.nsa.gov>
National Security Agency
More information about the Xcb