GNOME Bugzilla – Bug 542821
remove codegen copy in PyGTK and always use PyGObject's copy
Last modified: 2008-07-13 22:00:12 UTC
The subject says it all. For instance, I just merged two patches from PyGTK to PyGObject, because the latter's codegen got out of sync. Also, in PyGObject's 'codegen/argtypes.py' there is line "matcher.register('goffset', arg)", while in PyGTK there's not. However, I don't know what to do about this if anything. Patches follow.
Created attachment 114487 [details] [review] patch for PyGObject to activate its codegen After the patch it compiles, installs and works. However, I didn't know what to do with file 'dsextras.py'.
Created attachment 114488 [details] [review] patch for PyGTK to remove its codegen copy and use PyGObject's installed copy After the patch it compiles, installs and works, and it is also possible to make distribution ('make dist'). After the patch and full rebuild 'gtk.c' remains the same (it _is_ build with installed PyGObject codegen now), which is a good indication that codegen is the same as used before :) I didn't check if '.h' file scanning worked --- don't know how that's done. I didn't know what to do with these files: 'docs/random/update-bindings' and 'pygtk_postinstall.py'. I also don't know what happens on Windows.
Comment on attachment 114487 [details] [review] patch for PyGObject to activate its codegen let the win32 guys worry about dsextras.py
Comment on attachment 114488 [details] [review] patch for PyGTK to remove its codegen copy and use PyGObject's installed copy Thanks a lot Paul! I really wanted to do this for a long time, but I never got around doing it. I haven't looked at the patch in detail, but have you covered the following use case: 1) pygobject with codegen and pygtk without codegen? Should work. 2) pygobject with codegen and pygtk with codegen? Should work. 3) pygobject without codegen and pygtk without codegen? Should fail. I'm sure you tested 1. 2 should ideally work so distributions & users can migrate incrementally. 3 is good to have, not strictly necessary but trivial to implement by ensuring a recent pygobject version in pygtk's configure.ac.
1 obviously works, I test my patches at least a little before submitting ;). 2 works too, just tested: installed patched PyGObject and unpatched PyGTK --- no apparent problems, PyGTK just uses its own codegen. 3 fails at configure step with message "unable to find PyGObject codegen" (i.e. when you try to install new PyGTK without first installing patched PyGObject). About proper required version: I thought about it too, but maybe better to do right before releasing. I don't know what version this will apply to. Anyway, configure check should remain there just to filter out unexpected problems with somewhat helpful error message.
Committed PyGObject part. Sending ChangeLog Sending codegen/pygtk-codegen-2.0.in Sending pygobject-2.0.pc.in Transmitting file data ... Committed revision 795.
Okay, sound good then! Please commit! I'll probably do a pygobject release real soon now, this was the last pending task on my mental todo.
Before release, we really need more testing. Committing second patch: Sending ChangeLog Sending MANIFEST.in Sending Makefile.am Deleting codegen Sending configure.in Sending gtk/Makefile.am Deleting pygobject-2.0.pc.in Sending pygtk-2.0.pc.in Sending pygtk.spec.in Sending setup.py Transmitting file data ........ Committed revision 3006.