GNOME Bugzilla – Bug 788527
revert addition of env to python tools
Last modified: 2017-10-11 11:22:31 UTC
https://git.gnome.org/browse/glib/commit/?id=4395a8977727e2c569b472dbe8710ffb87c219e2 and https://git.gnome.org/browse/glib/commit/?id=683809d5f751575775d12917581eb7b9a2acf0f5 don't make sense: you go out of your way to find the path of the correct python binary and store it in PYTHON, so how does adding /usr/bin/env help? e.g., you end up with #!/usr/bin/env /usr/bin/python3.5 ?! I can see an argument for #!/usr/bin/env python or (the in my opinion better) #!/usr/bin/python3.5 but not what those patches have created. What where those patches trying to fix? In the meantime, please revert...
(In reply to Patrick Welche from comment #0) > What where those patches trying to fix? In the meantime, please revert... Are they actually causing problems for you? I’m not going to summarily revert a patch which obviously fixed something for someone unless it breaks other things more badly.
The commit messages explain why env is being used: it’s to handle the case where PYTHON is overridden by the --with-python argument to configure, which could be PYTHON=python, for example.
The help for the configure script `--with-python` option states: ``` Path to Python interpreter; searches $PATH if only a program name is given; if not given, searches for a few standard names such as "python3" or "python2" ``` This means we have to support both `python`, `python2`, or `python3` (and their minor version names), as well as a full path. Using `#!/usr/bin/env /usr/bin/python3` is perfectly supported by `env`.
So the issue is with --with-python, and therefore the solution should be in configure.ac. You beat me too it already closing this bug. I am delayed because it isn't at all clear what --with-python is designed to do: What does --without-python mean? POLS suggests, don't build gdbus-codegen and friend. The usual way to specify paths to be detected is by setting environment variables - just run ./configure --help to see lists of environment variables for most packages. What should happen if the user (erroneously) enters env PYTHON=python2 ./configure --with-python or env PYTHON=python2 ./configure --with-python=python3 It is not clear what should take priority, having read the configure.ac file. (Was the addition of --with-python thought through?)
(In reply to Patrick Welche from comment #4) > So the issue is with --with-python, and therefore the solution should be in > configure.ac. If you have a patch, feel free to attach it here. > What does --without-python mean? POLS suggests, don't build gdbus-codegen > and friend. I don't understand this sentence. > The usual way to specify paths to be detected is by setting environment > variables - just run ./configure --help to see lists of environment > variables for most packages. No, it's not "the usual way". The usual way is to follow what the configure help says — i.e. use `--with-python` in this case. > What should happen if the user (erroneously) enters > > env PYTHON=python2 ./configure --with-python > > or > > env PYTHON=python2 ./configure --with-python=python3 They will get a messy build. > It is not clear what should take priority, having read the configure.ac file. > > (Was the addition of --with-python thought through?) It was added 4 years ago for building GLib inside jhbuild (and other build environments); see bug 684103. I'd gladly review a patch that: - kept a `--with-python` configure option - kept the ability of using `python`, `python2`, `python3`, and minor version variants - did not overcomplicate the build or the various scripts, so that we can continue with the switch to Meson for the 2.56 development cycle.
In the interests of keeping the bug database tidy, I’m going to close this, since we don’t plan on providing a patch for it. Patrick, if you want to come up with a patch and attach it here, please re-open the report when you do so and I’ll gladly do a patch review. Thanks.
OK - any views on the 2 questions hidden in comment 4: - what should take priority? --with-python or env PYTHON ? - what should --without-python do? throw an error? (I was actually musing on a --with-python-tools so that people who just want the libraries can build on a python free cross compiler system, so --with-python-tools would just build the tools, and without would build everything else - passing comments?)
(In reply to Patrick Welche from comment #7) > OK - any views on the 2 questions hidden in comment 4: > > - what should take priority? --with-python or env PYTHON ? --with-python, since it's explicitly passed instead of inherited from the environment. > - what should --without-python do? throw an error? Yes; we have a hard dependency on Python at build time. > (I was actually musing on a > > --with-python-tools > > so that people who just want the libraries can build on a python free cross > compiler system, so --with-python-tools would just build the tools, and > without > would build everything else - passing comments?) That is not acceptable. You can build GLib without those tools, but anything using GLib/GObject/GIO *will* use those tools at build time, so building GLib without glib-mkenums/glib-genmarshal/gdbus-codegen is like building GLib without installing its headers: fine for run time, but pointless if you're planning to build anything else on top of it.