[Xcb] Python generator / cairo problems

[Jeremy A. Kolb]

On Mon, 21 Apr 2008, Eamon Walsh wrote:

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

I added a note in the error message about PYTHONPATH.

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

We'll need to be able to handle the documention tags in the XML.  Where do 
I stick those (see my previous email a few days ago that shows an example 
of the tags)?

> -- 
> Eamon Walsh <ewalsh at tycho.nsa.gov>
> National Security Agency
>