GNOME Bugzilla – Bug 320931
Build improvements for the python binding
Last modified: 2005-11-09 07:32:08 UTC
I'm attaching a patch that modernizes the python binding build stuff. Notably, it excludes python/vte.c from the dist. Right now as it stands, the file is disted, which means people's builds will not work unless they build against pygtk 2.8, which makes this bug somewhat important. I've made a couple minor cleanups to some non-python build stuff as well.
Created attachment 54450 [details] [review] The patch I can commit it myself if it looks good.
The root of the problem seems to be that pygtk-codegen-2.0 generates code incompatible which is not interchangeable between python 2.3 and 2.4, shouldn't that tool be versionned or support some flags? Also, I regenerated vte.c with a pygtk 2.6 pygtk-codegen-2.0, and now get: Python 2.3.5 (#2, Aug 30 2005, 15:50:26) [GCC 4.0.2 20050821 (prerelease) (Debian 4.0.1-6)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import vte Traceback (most recent call last):
+ Trace 63952
Please check bug 313454 too.
pygtk-codegen-2.0 generates code that works with both python 2.3 and 2.4, so that's not an issue. The above error is unrelated to this issue.
Commited. Thanks.
*** Bug 313454 has been marked as a duplicate of this bug. ***
My test environment was borken, I can "import vte" again. Can you confirm the following: - if someone builds vte's python bindings with pygtk 2.6, it will work with pygtk 2.8 - if someone builds vte's python bindings with pygtk 2.8, it will only work with pygtk 2.8 That seems natural, however: how do I check what version of pygtk the bindings need? If I can't, why not simply build all bindings with pygtk 2.6? Will I loose anything?
Yes, bindings built with pygtk 2.6 work with 2.8. Bindings built with 2.8 only work with 2.8. The minimum version a binding needs should be reflected in the configure script. It's also conceivable that a binding could optionally enable things based on what version it's being built against (e.g. cairo stuff). The vte stuff is pretty simple, and doesn't require anything beyond pygtk 2.0.0. As a distribution packager, just build against whatever the version that's current in the distro. So when unstable switches to pygtk 2.8, build against that.
Thanks for your answer. We discussed the problem further and concluded that there's no way to extract automatic strict dependencies from the resulting bindings, so we have to manually switch packages built with pygtk 2.8 to require pygtk >= 2.8 at runtime.