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 670718 - glib (gdbus-codegen) requires python2
glib (gdbus-codegen) requires python2
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: build
2.31.x
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
: 679086 (view as bug list)
Depends on:
Blocks: 684103
 
 
Reported: 2012-02-23 23:25 UTC by marc heiler
Modified: 2013-01-01 20:50 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
build: Add --disable-gdbus-codegen option (3.24 KB, patch)
2012-06-29 20:50 UTC, Colin Walters
none Details | Review

Description marc heiler 2012-02-23 23:25:45 UTC
How can I disable python?

Or is python now required

:(

Especially that python3 does not work ANNOYS me.
Comment 1 marc heiler 2012-02-23 23:27:15 UTC
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):                                                                                
  • File "../../gio/gdbus-2.0/codegen/gdbus-codegen", line 41 in <module>
    sys.exit(codegen_main.codegen_main())
  • File "/Depot/jjj/glib-2.31.16/gio/gdbus-2.0/codegen/codegen_main.py", line 171 in codegen_main
    parsed_ifaces = parser.parse_dbus_xml(xml_data)
  • File "/Depot/jjj/glib-2.31.16/gio/gdbus-2.0/codegen/parser.py", line 289 in parse_dbus_xml
    parser = DBusXMLParser(xml_data)
  • File "/Depot/jjj/glib-2.31.16/gio/gdbus-2.0/codegen/parser.py", line 57 in __init__
    self._parser.Parse(xml_data)
  • File "/Depot/jjj/glib-2.31.16/gio/gdbus-2.0/codegen/parser.py", line 155 in handle_start_element
    if attrs.has_key('name') and self.doc_comment_last_symbol == attrs['name']:

Comment 2 André Klapper 2012-02-24 13:30:04 UTC
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?
Comment 3 marc heiler 2012-02-25 03:59:26 UTC
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. ;<
Comment 4 André Klapper 2012-02-25 17:33:57 UTC
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. :)
Comment 5 Colin Walters 2012-02-26 10:50:02 UTC
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.
Comment 6 marc heiler 2012-03-03 23:08:36 UTC
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)
Comment 7 Colin Walters 2012-03-05 14:02:34 UTC
(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.
Comment 8 Colin Walters 2012-06-29 20:50:24 UTC
*** Bug 679086 has been marked as a duplicate of this bug. ***
Comment 9 Colin Walters 2012-06-29 20:50:53 UTC
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.
Comment 10 Matthias Clasen 2012-06-30 04:18:04 UTC
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 ?
Comment 11 Colin Walters 2012-06-30 13:42:43 UTC
(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.
Comment 12 Colin Walters 2012-08-28 12:25:55 UTC
(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.
Comment 13 Simon Feltman 2012-09-29 08:59:42 UTC
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
Comment 14 Matthias Clasen 2012-11-09 23:13:36 UTC
I'd rather see a --with-python configure option than a --disable-python option
Comment 15 Matthias Clasen 2013-01-01 20:50:55 UTC
--with-python has been added now