After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 320931 - Build improvements for the python binding
Build improvements for the python binding
Status: RESOLVED FIXED
Product: vte
Classification: Core
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
: 313454 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-11-08 02:45 UTC by Manish Singh
Modified: 2005-11-09 07:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
The patch (3.42 KB, patch)
2005-11-08 02:45 UTC, Manish Singh
none Details | Review

Description Manish Singh 2005-11-08 02:45:17 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.
Comment 1 Manish Singh 2005-11-08 02:45:50 UTC
Created attachment 54450 [details] [review]
The patch

I can commit it myself if it looks good.
Comment 2 Loïc Minier 2005-11-08 13:21:32 UTC
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):
  • File "<stdin>", line 1 in ?
ImportError: could not import gtk._gtk

Please check bug 313454 too.
Comment 3 Manish Singh 2005-11-08 19:40:07 UTC
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.
Comment 4 Kjartan Maraas 2005-11-08 20:19:05 UTC
Commited. Thanks.
Comment 5 Loïc Minier 2005-11-08 21:37:34 UTC
*** Bug 313454 has been marked as a duplicate of this bug. ***
Comment 6 Loïc Minier 2005-11-08 22:04:37 UTC
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?
Comment 7 Manish Singh 2005-11-08 23:46:51 UTC
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.
Comment 8 Loïc Minier 2005-11-09 07:32:08 UTC
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.