GNOME Bugzilla – Bug 658174
use a different pkgconfig for pygobject compiled with python3 support
Last modified: 2011-09-16 09:12:20 UTC
Right now pygobject compiled with python2 and python3 cannot be installed in parallel. Is easy to split out documentation and header(if it will be preserved identical) but i cannot split out the pkgconfig because is different. diff -Nur python/usr/lib/pkgconfig/pygobject-3.0.pc python2/usr/lib/pkgconfig/pygobject-3.0.pc --- python/usr/lib/pkgconfig/pygobject-3.0.pc 2011-09-02 19:02:33.000000000 +0000 +++ python2/usr/lib/pkgconfig/pygobject-3.0.pc 2011-09-02 19:02:36.000000000 +0000 @@ -12,7 +12,7 @@ fixxref=${datadir}/pygobject/xsl/fixxref.py pygdocs=${datadir}/gtk-doc/html/pygobject defsdir=${datadir}/pygobject/2.0/defs -overridesdir=${exec_prefix}/lib/python3.2/site-packages/gi/overrides +overridesdir=${exec_prefix}/lib/python2.7/site-packages/gi/overrides Name: PyGObject Description: Python bindings for GObject
I think, hardcoded references to python paths should not be here. Python path should be passed as another variable at build-time instead.
(In reply to comment #1) > I think, hardcoded references to python paths should not be here. Python path > should be passed as another variable at build-time instead. The issue is how do we let third party libs to know where to install their overrides.
The only "variable" part of this variable seems to be "gi/overrides". We can leave this part here in this pkg-config file and let third party developers figure out python version/home (which is a variable for Arch Linux) on their own during at build-time. Possible Fix 1: $ cat /usr/lib/pkgconfig/pygobject-3.0.pc | grep overridesdir overridesdir=${exec_prefix}/lib/python${python_ver}/site-packages/gi/overrides $ pkg-config --define-variable python_ver=3.2 --variable overridesdir pygobject-3.0 /usr/lib/python3.2/site-packages/gi/overrides $ pkg-config --define-variable python_ver=2.7 --variable overridesdir pygobject-3.0 /usr/lib/python2.7/site-packages/gi/overrides Possible Fix 2: $ cat /usr/lib/pkgconfig/pygobject-3.0.pc | grep overridesdir overridesdir=${python_home}/site-packages/gi/overrides $ pkg-config --define-variable python_home=/usr/lib/python3.2 --variable overridesdir pygobject-3.0 /usr/lib/python3.2/site-packages/gi/overrides $ pkg-config --define-variable python_ver=/usr/lib/python2.7 --variable overridesdir pygobject-3.0 /usr/lib/python2.7/site-packages/gi/overrides
It is conceivable that overrides could eventually go into a non versioned directory. The purpose is for libs to just be able to throw their overrides wherever the os installed gi to. Most likely the best fix would be to get that directory not from package config but from gi itself - import gi gi.get_overrides_dir() that way they get the correct directory depending on how they compiled pygobject and which version of python they used.
(In reply to comment #4) > It is conceivable that overrides could eventually go into a non versioned > directory. The purpose is for libs to just be able to throw their overrides > wherever the os installed gi to. Most likely the best fix would be to get that > directory not from package config but from gi itself - > > import gi > gi.get_overrides_dir() > > that way they get the correct directory depending on how they compiled > pygobject and which version of python they used. I like that idea. Can be implemented in a simple way too with something like this in gi/__init__.py: def get_overrides_dir(): return os.path.join(os.path.dirname(__file__), 'overrides')
Well, I would want it to be configurable during the configure stage but this would work for now. I need to find out who consumes this and see if it is ok with them.
ok, you can now access the overrides dir with gi._overridesdir
thanks. much better than renaming pkgconfig files.