[Xcb] Python generator / cairo problems

[Eamon Walsh]

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:
>>
>>     
>>> Ian,
>>>
>>> Are you refering to Felix Rabe's email?  It looks like he sorted it
>>> out.
>>>
>>> Jeremy
>>>
>>> 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.


>>>> Ian
>>>>
>>>>         
>> 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 
either library.

>> (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."

>> Ian
>>     
>
> 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