python & perl bindings don't support custom INSTALL_PREFIX

[GoogleCodeExporter]

Building libproxy-0.4.3 via JHBuild fails. JHBuild installs to a sandbox for 
testing and defines cmake's INSTALL_PREFIX. libproxy attempts to install to 
/usr/lib64/python2.6/site-packages and /usr/lib64/perl5 which don't have write 
permission.

The attached patch corrects the issue. Tested with JHBuild.

Original issue reported on code.google.com by craig.s....@gmail.com on 11 Jun 2010 at 3:50

Attachments:

• libproxy-0.4-python-libdir.patch

[GoogleCodeExporter]

The patch can't be correct:

-           -c "import distutils.sysconfig ; print 
distutils.sysconfig.get_python_lib(plat_specific=0)"
-           OUTPUT_VARIABLE pysitepkgdir
+           -c "import distutils.sysconfig ; print 
distutils.sysconfig.get_python_version()"
+           OUTPUT_VARIABLE pyversion
            OUTPUT_STRIP_TRAILING_WHITESPACE)
-    install(FILES libproxy.py DESTINATION ${pysitepkgdir})
+    install(FILES libproxy.py DESTINATION 
${libdir}/python${pyversion}/site-packages)

we're installing in arch-independent site-package and as such using ${libdir} 
can only be wrong. 

(as a side note: I do packaging for openSUSE, where none of the packages is 
being built / make install'ed as root, and 0.4.3 builds fine).

the patch at best 'hides' some issues which you might have.
Please check with make VERBOSE=1 and make install VERBOSE=1 to see if there is 
not something else missing.

Original comment by dominiqu...@gmail.com on 11 Jun 2010 at 3:13

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Building as root works fine. Building as a user does not.
Agree, the patch isn't perfect but libproxy needs to respect 
CMAKE_INSTALL_PREFIX for Python and Perl modules.

Original comment by craig.s....@gmail.com on 12 Jun 2010 at 12:40

[GoogleCodeExporter]

I just submitted new packages for fedora with 0.4.4 and this appears to work 
there.  Have you tried 0.4.4?

Original comment by npmccallum@gmail.com on 13 Jun 2010 at 6:30

[GoogleCodeExporter]

No, 0.4.4 doesn't work. (Tries to install to /usr/lib/python2.6/ rather than 
/opt/gnome2/lib64/python2.6)

-- Installing: /opt/gnome2/lib64/pkgconfig/libproxy-1.0.pc
-- Installing: /opt/gnome2/share/cmake/Modules/Findlibproxy.cmake
-- Installing: /opt/gnome2/lib64/libproxy.so.1.0.0
-- Up-to-date: /opt/gnome2/lib64/libproxy.so.1
-- Up-to-date: /opt/gnome2/lib64/libproxy.so
-- Removed runtime path from "/opt/gnome2/lib64/libproxy.so.1.0.0"
-- Installing: /opt/gnome2/include/proxy.h
-- Installing: /usr/lib/python2.6/site-packages/libproxy.py
CMake Error at bindings/cmake_install.cmake:36 (FILE):
  file INSTALL cannot copy file
  "/home/oxyde/gnome2/libproxy-0.4.4/bindings/libproxy.py" to
  "/usr/lib/python2.6/site-packages/libproxy.py".
Call Stack (most recent call first):
  cmake_install.cmake:39 (INCLUDE)

Original comment by craig.s....@gmail.com on 14 Jun 2010 at 9:08

[GoogleCodeExporter]

The difference between what craig tries (which fails) and what *we* packagers 
do is in the way we configure / build and what we expect.

We packagers also build as non-root (which is probably standard by now) but we 
intend to end up in the 'base system' with our packages.

So we do
cmake -DCMAKE_INSTALL_PREFIX=/usr .
make
make install DESTDIR=/tmp/installroot

whereas /tmp/installroot is after the content of the package

For perl and python, the installation out ouf the system root is almost 
useless, as, unless specifically crafted, applications will not find the 
extensions there.

No idea though what and how we can avoid this conflict without breaking regular 
usage (and no, $libdir can't be used here... we need to follow distributions 
instructions on where modules have to end up).

An option could be to specifically have a PATH CACHE for those folders and have 
them by default on what the distro provides (something similar is done already 
with perl, where we choose between vendorlib and regular lib).

Original comment by dominiqu...@gmail.com on 14 Jun 2010 at 5:03

[GoogleCodeExporter]

Original comment by nicolas.dufresne@gmail.com on 18 Aug 2010 at 6:47

• Added labels: Milestone-Release0.4.5

[GoogleCodeExporter]

you can now use PX_PERL_ARCH (r729) and PYTHON_SITEPKG_DIR (r728) to override 
Perl and Python installation directory. Note that this will usually just not 
work unless you manually tell Perl and Python that there is more bindings in 
those custom folders.

Original comment by nicolas.dufresne@gmail.com on 19 Aug 2010 at 3:18

• Changed state: Fixed