GNOME Bugzilla – Bug 670718
glib (gdbus-codegen) requires python2
Last modified: 2013-01-01 20:50:55 UTC
How can I disable python? Or is python now required :( Especially that python3 does not work ANNOYS me.
Configure stage works fine and generates the Makefile. However running "make" leads to error explosion: ake[4]: Entering directory `/Depot/jjj/glib-2.31.16/gio/tests' GEN gdbus-test-codegen-generated.c Traceback (most recent call last):
+ Trace 229733
sys.exit(codegen_main.codegen_main())
parsed_ifaces = parser.parse_dbus_xml(xml_data)
parser = DBusXMLParser(xml_data)
self._parser.Parse(xml_data)
if attrs.has_key('name') and self.doc_comment_last_symbol == attrs['name']:
See configure.ac: # Need suitable python path for greport AM_PATH_PYTHON(2.5,,PYTHON="/usr/bin/env python2.5") How is your comment 1 related to commtn 0?
I don't know why bugzilla made this strange "Trace" thing. I just copy/pasted the error I had in the console, so that you developers believe me when I say that the python3 version did not work at all for me. Problem is, right now I can only work with python3, so for me this is a no-go stage now as I can not use python2. :( Is it not possible to have a python3 compatible script? Or a check to load the proper python version? It's very inconvenient to have to use a python2 in order to get glib to compile. But I guess there is no way around that? Still, I am not happy at all about this. Even using perl5 would be better because they'd at least be stable and not change to incompatible versions. ;<
So what is this bug report about, in one sentence? "Cannot compile glib with Python3"? Note that this is not a forum but a bugtracker so please try to keep things focussed. :)
The gdbus-codegen tool requires Python 2. We could give you a configure option to disable it if you're not going to use it for your project. It may not be hard to make it work under *both* Python 2 and 3.
Andre, if you need just one sentence, here you go: - Add python3 support for compilation. There you go. No need to read the rest if you are just interested in one sentence Andre. I make a line break with '-' so Andre does not have to continue reading. ;) --------------------------------------------- I am aware that you are not to be blamed for the python2 to python3 mess, as the python language changed. I also do not intend to use the bugtracker as a forum, but if I would just make one sentence like "- Add python3 support for compilation." I am sure there would have been people to ask "Can you give more details." I don't intend to use it as a forum either. My bug report is that I require python2 in order to specifically compile glib now. And if I try to switch to python3, certain projects no longer compile, which forces me to also keep a copy of python2 for compatibility reasons (if I want to compile from source on my own, which I do.) I believe this has not been the case in the past that python was such a hard dependency, and specifically an older version of python. If memory serves me right, past glib versions did not require python. At least I don't recall an error like this with other, older glib versions. "The gdbus-codegen tool requires Python 2. We could give you a configure option to disable it if you're not going to use it for your project. It may not be hard to make it work under *both* Python 2 and 3." That would be great, if that would be possible. A user could compile glib but disable python bindings altogether at this stage at least. As an option. For my use case, I often try out the latest changes in Gtk/Atk/Pango/Glib, so it would be helpful for me to be as agile as possible when upgrading. Please, if it is possible to disable python, it would be nice to be able to. I grepped through the configure --help options and did not see a: --disable-python option yet. Perhaps such a small option could be used, with a description like: --disable-python | Disable the use of gdbus-codegen (this script depends on python 2.x right now)
(In reply to comment #6) > > That would be great, if that would be possible. A user could compile glib but > disable python bindings altogether at this stage at least. As an option. > > For my use case, I often try out the latest changes in Gtk/Atk/Pango/Glib, so > it would be helpful for me to be as agile as possible when upgrading. > > Please, if it is possible to disable python, it would be nice to be able to. If there was such an option, you might be able to compile Pango and Atk, but if e.g. Gtk+ ever used gdbus-codegen then it would fail to build if your glib had been built with --disable-codegen or whatever we called it. I can certainly imagine some valid uses such as embedding on Windows where you just want a GLib to ship with your app, and don't want gdbus-codegen (or Python), so it does make sense to provide the option. But it won't magically work for replacing Python 2 with Python 3.
*** Bug 679086 has been marked as a duplicate of this bug. ***
Created attachment 217660 [details] [review] build: Add --disable-gdbus-codegen option Some consumers of GLib aren't using the GDBus code generator, and it adds a dependency on Python, which may not be desired. Allow disabling it.
Review of attachment 217660 [details] [review]: I must say I feel the same way about this as Benjamin does about --without-atk-bridge. Every configure option hurts. If the python dependency is a problem, then maybe we can get the people who are hurt by it to rewrite the code generator in C ?
(In reply to comment #10) > Review of attachment 217660 [details] [review]: > > I must say I feel the same way about this as Benjamin does about > --without-atk-bridge. Every configure option hurts. Yeah, it's a tradeoff. The main concern I have about this option is that some of the "distributions" might try to use it, but that would break compilation of the variety of components (udisks, etc.) that do use the code generator. However GLib is component that gets used in a wide variety of ways. For an embedded system for example, would seem quite likely to me is that they would want to be able to compile GLib twice - once natively, and once for the target system. The native build would have the code generator, and be used to cross build for the target. In this scenario the target compilation would use --disable-gdbus-codegen since it's not needed, and this would help avoid having Python on the target system. The other use case for this option is GLib backporting. In OSTree I'm embedding glib so I can run on quite old systems: http://git.gnome.org/browse/ostree/tree/embedded-dependencies/Makefile.am I'm not using the gdbus codegen there. Right now my build system just tosses away the code generator files, but if we were to ever update the configure script to actually check for Python 2.7, it would break building on RHEL6, even though I'm not using the codegen. > If the python dependency is > a problem, then maybe we can get the people who are hurt by it to rewrite the > code generator in C ? Yeah, possibly. I kind of regret having g-ir-scanner in Python now to be honest because it's this whole other dependency stack where I can't use the good stuff from GLib. Anyways bottom line - this build option would likely be useful for embedded systems, and I would definitely use it in ostree-embeddeps.
(In reply to comment #11) > > Anyways bottom line - this build option would likely be useful for embedded > systems, and I would definitely use it in ostree-embeddeps. This is still the case.
The original request from the reporter has been fixed in: https://bugzilla.gnome.org/show_bug.cgi?id=678066 So perhaps tickets title should be changed to something like: "Add --disable-gdbus-codegen flag as build configuration option" This will reflect the remaining discussion and patch that has been added. In this, case it also does not need to be a blocker for: https://bugzilla.gnome.org/show_bug.cgi?id=684103
I'd rather see a --with-python configure option than a --disable-python option
--with-python has been added now