GNOME Bugzilla – Bug 353849
The setup.py script should be updated for pygtk-2.10 (and pygobject-2.12)
Last modified: 2006-09-25 12:54:54 UTC
The setup.py distutils script is commonly used on win32 to build both pygtk and pygobject. On CVS, setup.py uses dsextras which is part of pygobject. Quite interestingly, the dsextras.Template and dsextras.TemplateExtension classes process defs files using codegen which is part of pygtk !!! The enclosed patches for pygobject and pygtk: 1. move Template and TemplateExtension to a new file dsextras_gen.py in the pygtk distribution. 2. update the setup.py scripts for pygtk and pygobject CVS 3. add support for defs files built at configure time using createdefs, as required for the gtk and gdk 2.10 bindings. Please note that, with these patches applied, GTK+-2.10 is required to build pygtk CVS on win32 but it should be quite straightforward to support both 2.8 and 2.10 as with the configure approach. Even though I have commit access to CVS, I think it is better to post my proposed changes here to have first some kind of external reviewing process. Both pygobject and pygtk CVS were tested against some homebuilt win32 binaries of GTK+, as no "official" GTK+ 2.10 files have been posted for win32 yet (by either Tor or Ivan Wong from gladewin32).
Created attachment 72021 [details] [review] Update distutils-based building framework on win32 for pygtk-2.12
Created attachment 72022 [details] [review] Update distutils-based building framework on win32 for pygtk-2.10
Created attachment 72023 [details] [review] Update distutils-based building framework on win32 for pygobject-2.12
We're planning to move over codegen to pygobject at some point, I'm not sure it makes sense to move dsextras.py back.
Any idea when this move will be done ? I have no problem keeping everything in dsextras but then codegen must be part of and installed by pygobject to avoid cross-dependency problems on win32.
Doesn't pygobject build without codegen? Yes, the current situation is a mess but things can probably be made to work without moving codegen.
Yes, pygoject can be built without codegen, as setup.py does not use dsextras.Template or dsextras.TemplateExtension. Nevertheless, pygobject installs dsextras.py, which means that any external projet that uses dsextras.Template or dsextras.TemplateExtension will fail IF pygtk is not installed with pygoject. Hence my proposal to move Template and TemplateExtension to a new file dsextras_gen.py which requires codegen and will be part of pygtk.
No one disagrees that codegen shouldn't be moved to pygobject. I'm just trying to narrow the scope of the bug so that setup.py can be fixed even before codegen is moved.
Ok, so what about keeping everything in dsextras.py (in pygtobject) and checking for the availability of codegen: 1. codegen is available: import it from dsextras. 2. codegen is not available (the user has only installed pygobject): print a warning stating that the Template and TemplateExtension classes will only be available if the user also install pygtk. This way, if codegen is ultimately moved to pygobject, we will only have to remove this conditional import of codegen on dsextras ! If agreed, I can submit an updated patch that implements this approach. As a sidenote, shouldn't setup.py also take care of installing the pygobject and pygtk reference docs ?
Created attachment 72247 [details] [review] Fix distutils-based building framework on win32 for pygobject-2.12 (updated)
Created attachment 72248 [details] [review] Fix distutils-based building framework on win32 for pygtk-2.10 (updated)
I updated my patches: 1. Template and TemplateExtension were moved back to dsextras.py. No dsextras_gen.py file anymore. 2. dsextras import codegen if present or warns the user about the availability of codegen in the pygtk distribution. 3. HTML reference docs are now installed, along with the XSL files. For pygtk, fixxref is run at install time (in the postinstall.py files). Still TODO: check for the GTK+ version and conditionally add gtk-2.10.defs and gtk-2.10-types.defs to the build.
Comment on attachment 72247 [details] [review] Fix distutils-based building framework on win32 for pygobject-2.12 (updated) >Index: dsextras.py [lots of deleted code] >+try: >+ from codegen.override import Overrides >+ from codegen.defsparser import DefsParser >+ from codegen.codegen import register_types, SourceWriter, FileOutput >+ import codegen.createdefs >+ >+ class Template: [lots of added code] >+except ImportError, e: [snip] It seems unnecessary to use such a big try/except, when it's only the imports in the beginning that will raise the ImportError we're interested in. I haven't checked the xsl/documentation patches in detail, but I assume that xsltproc is not required for anyone who wishes to read the documentation.
About the exception : right, could be replaced by a return. Here I wanted to use the exception as the equivalent of a big #ifdef to make it clear that Template and TemplateExtension should not be defined if codegen is not available. Hence the big try/except. About the xsl/documentation: of course xsltproc is not required to read the documentation. Here, I simply mirrored the installation step described in pygobject/docs/Makefile where the xsl files are explicitly installed in $(datadir)/pygobject/xsl: XSLdir = $(datadir)/pygobject/xsl XSL_DATA = $(XSL_FILES) $(FIXXREF) along with the html documentation and the style file: CSSdir = $(HTMLdir) CSS_DATA = $(CSS_FILES) HTMLdir = $(datadir)/gtk-doc/html/pygobject HTML_DATA = $(HTML_FILES)
Created attachment 72318 [details] [review] Fix distutils-based building framework on win32 for pygobject-2.12 (updated #2) Maybe you prefer this for the try...except clause around the codegen import ?
I have added a few features: 1. Conditional build of the 2.10 pygtk binding if GTK+ 2.10 is detected. 2. Creation of shortcuts to the pygobject and pygtk reference manuals in the "Start Menu", along with a link to the PyGTK homepage. Tha patches are against CVS HEAD. What do you think ? Is it ready to be commited to CVS ?
Created attachment 72598 [details] [review] Fix distutils-based building framework on win32 for pygobject-2.12 (update #3)
Created attachment 72599 [details] [review] Fix distutils-based building framework on win32 for pygtk-2.10 (update #3)
Cedric: It looks all fine to me. I don't really use distutils, it's only there for win32 installer support and jpe which refuses to use autotools :-)
A few comments: 1) I needed to change line 70 of setup.py when compiling with VC++ because of the different quoting rules in the cmd.exe shell. What works for me is: GLOBAL_MACROS.append(('VERSION', '"""%s"""' % VERSION)) This may not work with the cygwin / mingw sh though. A better option may be to stringify VERSION in pygobject.h rather than include the " characters in the macro itself. This would require changes to the makefiles, though. 2) The warning that the codegen is missing when pygobject is built is a bit misleading. It may be better to display the message if and when codegen is actually needed. 3) I'm a bit dubious of installing a link to the documentation, though I can see why others might like it. My use case is that I have multiple versions built and installed in different places and the link would end up pointing to the last one installed -- I'd be happy with a flag to not install. As far as if it's a generally a good idea to include, it probably is for developers who are writing pygtk code but it'll be confusing for application end users. I'm just leery of touching anything that's essentially a global singleton.
Comments on jpe's comments: 1. Agreed on that one. GLOBAL_MACROS.append(('VERSION', '"""%s"""' % VERSION)) also works with mingw32/cygwin. 2. Right. You have a solution in mind ? I guess the best would be to move the codegen import, exception and warning message to the Template class constructor, then raise a NameError exception to be caught by the user of either Template or TemplateException. 3. Unfortunately I have no clue about the proper way to pass options to the bdist_wininst generated installer or to add a "Install documentation" checkbox to the installer interface through pygtk_postinstall.py. Anyway, I also found out in the meantime (by looking at the pywin32 code) that I should be more careful about the target location for the pygtk shortcuts. Depending on the user rights (admin, limited user), shortcuts should be created system-wide or only for the current user (CSIDL_COMMON_STARTUP). So it might be better to comment out shortcuts creation for the time being and come back to that later. Waiting for your proposed solution to point 2 before resubmitting patches...
I came up with (what I believe is) an elegant solution to comment #2. It essentially overloads the __new__ method of the Template class. See my updated patches. I also disabled shortcut creation in the Start Menu and now define VERSION using GLOBAL_MACROS.append(('VERSION', '"""%s"""' % VERSION))
Created attachment 72681 [details] [review] Fix distutils-based building framework on win32 for pygobject-2.12 (update #4)
Created attachment 72682 [details] [review] Fix distutils-based building framework on win32 for pygtk-2.10 (update #4)
Created attachment 73029 [details] [review] Fix distutils-based building framework on win32 for pygobject-2.12 (update #5) The solution I proposed as patch #4 for the conditional import of codegen in dsextras had some flaws. The attached patch proposes an alternative implementation.
Created attachment 73030 [details] [review] Fix distutils-based building framework on win32 for pygtk-2.10 (update #5) This patch is an update to my previous patch. It fixes a bug when the windows uninstaller is called for pygtk. style.css, copied from the pygobject root directory at install time, is now deleted when pygtk is uninstalled.
This works for me in a simple test and probably should be committed. The warnings about codegen when building pygobject are gone. I've never used the distutils based binary installer so don't have ideas on how to make it work.
I also built pygobject and pygtk for python 2.5 this morning and everything works fine. If you agree, I will commit my changes for the time being. I'd like to release pygtk-2.10 and pygobject-2.12 binaries as soon as possible.
I don't have any objections
Done. Let's close this bug for the time being.
*** Bug 356556 has been marked as a duplicate of this bug. ***