Python, cmake and local installs
David García Garzón
source packages have an option like --prefix to install it at your home, at
/usr or at /usr/local, C:/freenect or wherever. If I understod it well such
option in cmake (and freenect) is CMAKE_INSTALL_PREFIX and it works for
libfreenect unless you enable the python wrapper. In my Ubuntu, I try to set
the prefix to ~/local and CMake still tries to install the python module at
/usr/lib/python2.6/dist-packages, which needs administration rights.
Changing wrappers/python/CMakeLists.txt:12:
# Figure out installation path
execute_process(COMMAND
${PYTHON_EXECUTABLE} -c "from distutils.sysconfig import get_python_lib;
print get_python_lib(plat_specific=True, prefix='')"
OUTPUT_VARIABLE PYTHON_SITE_PACKAGES OUTPUT_STRIP_TRAILING_WHITESPACE)
Returns a relative package and CMAKE_INSTALL_PREFIX is automatically prepended
so it is installed at ~/local/lib/python2.6/dist-packages. Anyway although
this solves most installation problems (installing in /usr/local and so on),
this does not fully solves my problem because when python modules are
installed in a user dir (with normally is done by the --home=<path> option)
modules should be installed in a simpler layout, say <path>/lib/python.
A simple line adition at wrappers/python/CMakeLists.txt:14:
set(PYTHON_SITE_PACKAGES "lib/python")
which works perfect for me but then it breaks the former solution for
alternative install paths.
I am a newbie both with distutils hacking and cmake, so, i don't know which is
the preferred strategy for solving that. Can anyone find any better solution to
this problem? Maybe an extra cmake option for local installs? Autodetection
from CMAKE_INSTALL_PREFIX?
There is some information about python installation paths in distutils
documentation [1], and you can see some concrete cases for paths in
distutils/command/install.py in your python standard lib location.
[1] http://docs.python.org/install/index.html
--
David García Garzón
(Work) david dot garcia at upf anotherdot edu
http://www.iua.upf.edu/~dgarcia
bwh...@dappervision.com
David García Garzón
> Try using setup.py to install the wrapper, I didn't make the cmake
> installer and it has been causing problems for people.
I am not asking for a work arround. I have it working. With setup, as you say,
first, and then with the kludges i wrote in my previous mail. But I just want
cmake to stop causing problems for people because i understand that cmake is
the way to go for the project, although distutils is smarter than cmake for
python installs, we agree on that.
The main problem with the changes i proposed in my previous mail is that each
change worked just for one python installation schema: prefix or home.
The prefix solution is by itself an step forward as it still works in the same
cases cmake worked until now and it enables installs in /usr/local or
wherever. For home installs i propose to add a cmake option (like
PYTHON_HOME_INSTALL) to enable it. Autodetection could also work but i cannot
think on a reliable way to autodetect that.
I am a newbie with both cmake and distutils so i was calling for ideas or
better solutions to fix the python cmake.
Yaroslav Halchenko
On Thu, 10 Feb 2011, David García Garzón wrote:
> On Wednesday 09 February 2011 20:56:29 Yaroslav Halchenko wrote:
> > On Wed, 09 Feb 2011, Brandyn White wrote:
> > > This person appears to be having issues with the cmake python install
> > > [1]https://groups.google.com/d/topic/openkinect/yIjeMeIKvdc/discussion
> > yes -- this sounds in line with my pull request:
> > https://github.com/OpenKinect/libfreenect/pull/198
> > David, could you please have a look at it? with it, it should respect
> > CMAKE_INSTALL_PREFIX, e.g. with
> > -DCMAKE_INSTALL_PREFIX:String=$HOME/local
> > you would obtain:
> > -- Install configuration: ""
> > -- Installing: /home/yoh/local/lib64/libfreenect.so.0.0.1
> > -- Installing: /home/yoh/local/lib64/libfreenect.so.0.0
> > -- Installing: /home/yoh/local/lib64/libfreenect.so
> > -- Installing: /home/yoh/local/lib64/libfreenect.a
> > -- Installing: /home/yoh/local/include/libfreenect/libfreenect.h
> > -- Installing: /home/yoh/local/lib64/pkgconfig/libfreenect.pc
> > -- Installing: /home/yoh/local/bin/glview
> > -- Removed runtime path from "/home/yoh/local/bin/glview"
> > -- Installing: /home/yoh/local/bin/glpclview
> > -- Removed runtime path from "/home/yoh/local/bin/glpclview"
> > -- Installing: /home/yoh/local/bin/tiltdemo
> > -- Removed runtime path from "/home/yoh/local/bin/tiltdemo"
> > -- Installing: /home/yoh/local/lib64/fakenect/libfreenect.so.0.0.1
> > -- Installing: /home/yoh/local/lib64/fakenect/libfreenect.so.0.0
> > -- Installing: /home/yoh/local/lib64/fakenect/libfreenect.so
> > -- Installing: /home/yoh/local/lib64/libfreenect_sync.so.0.0.1
> > -- Installing: /home/yoh/local/lib64/libfreenect_sync.so.0.0
> > -- Installing: /home/yoh/local/lib64/libfreenect_sync.so
> > -- Removed runtime path from
> > "/home/yoh/local/lib64/libfreenect_sync.so.0.0.1" -- Installing:
> > /home/yoh/local/lib64/libfreenect_sync.a
> > -- Installing: /home/yoh/local/include/libfreenect/libfreenect_sync.h
> > -- Installing: /home/yoh/local/include/libfreenect.hpp
> > -- Installing: /home/yoh/local/bin/cppview
> > -- Removed runtime path from "/home/yoh/local/bin/cppview"
> > -- Installing: /home/yoh/local/lib/python2.6/site-packages/freenect.so
> > -- Removed runtime path from
> > "/home/yoh/local/lib/python2.6/site-packages/freenect.so"
> > is that what you were aiming at?
> > is that what you were aiming at?
> Yep, this shoud solve the prefix python install schema, and should be pretty
> equivalent to the change i did. I don't know whether inserting the variable as
> prefix or letting the prefix in blank to obtain a relative path it is better
> or more problematic. If left in blank, cmake will insert the prefix.
> I added the plat_specific=True option as the module is platform specific.
> (compiled C, not pure python). Distutils does the difference and I guess it is
> needed to be correct unix but i don't know myself of a system that requires it
> or whether setting that flag would suffice.
> And last but not least both codes have the problem of being unable to make a
> 'home' install. The problem is that just not only changes the prefix but also
> the layout within that prefix. And the paradigmatic case of libs that in
> 'home' schema are installed simply in <path>/lib/python/. See
> http://docs.python.org/install/index.html
> As solution for 'home' install I was suggesting a different cmake flag to
> activate the 'home' schema. For sure you know more clearly how to do that
> properly in cmake.
> And the ideal solution i couldn't find was a way of making those schemas
> defined at distutils/command/install.py available to cmake but that maybe is
> rocket science.
> David.
Yaroslav Halchenko
> prefix or letting the prefix in blank to obtain a relative path it is better
> or more problematic. If left in blank, cmake will insert the prefix.
> I added the plat_specific=True option as the module is platform specific.
> (compiled C, not pure python). Distutils does the difference and I guess it is
> needed to be correct unix but i don't know myself of a system that requires it
> or whether setting that flag would suffice.
elif os.name == "nt":
if standard_lib:
return os.path.join(prefix, "Lib")
else:
if get_python_version() < "2.2":
return prefix
else:
return os.path.join(prefix, "Lib", "site-packages")
elif os.name == "mac":
if plat_specific:
if standard_lib:
return os.path.join(prefix, "Lib", "lib-dynload")
else:
return os.path.join(prefix, "Lib", "site-packages")
else:
if standard_lib:
return os.path.join(prefix, "Lib")
else:
return os.path.join(prefix, "Lib", "site-packages")
So I do not mind having it -- would have no effect on *xes
> And last but not least both codes have the problem of being unable to make a
> 'home' install. The problem is that just not only changes the prefix but also
> the layout within that prefix. And the paradigmatic case of libs that in
> 'home' schema are installed simply in <path>/lib/python/. See
> http://docs.python.org/install/index.html
Please correct me if I am wrong -- it is pretty much specific only for the Python module, right? the rest goes conventionally as it simply had CMAKE_INSTALL_PREFIX=$HOME, right?
David García Garzón
> > I don't know whether inserting the variable
>
> as
>
> > prefix or letting the prefix in blank to obtain a relative path it is
>
> better
>
> > or more problematic. If left in blank, cmake will insert the prefix.
>
> None prefix makes it default prefix (e.g. '/usr'), blank prefix, makes it
> ... blanke (e.g. ''), having CMAKE_INSTALL_PREFIX as the prefix -- makes
> installation inline with the rest of libfreenect (i.e. where users asked it
> to deploy -- '/usr' or '/usr/local' or elsewhere).
I don't mind which one you choose but let me recall you that having "" as
prefix also works because it renders into relative paths, which used in an
install target makes cmake to insert CMAKE_INSTALL_PREFIX automagically.
The effect in unix is because this preceding code:
if prefix is None:
prefix = plat_specific and EXEC_PREFIX or PREFIX
If your install have a diferent PREFIX than EXEC_PREFIX you will notice the
difference. PREFIX and EXEC_PREFIX are the ones for python install (not for
our module install). Most systems have them defined the same but in
multiplatform systems it could crazy. Any way we can drop it and add it when
someone complains because I don't know how to test it.
> > And last but not least both codes have the problem of being unable to
> > make
>
> a
>
> > 'home' install. The problem is that just not only changes the prefix but
>
> also
>
> > the layout within that prefix. And the paradigmatic case of libs that in
> > 'home' schema are installed simply in <path>/lib/python/. See
> > http://docs.python.org/install/index.html
>
> Thanks for reminding me about such setup... being a Debian developer I
> rarely do 'local' or 'home' installs ;) so forgotten about its existence.
> Please correct me if I am wrong -- it is pretty much specific only for the
> Python module, right? the rest goes conventionally as it simply had
> CMAKE_INSTALL_PREFIX=$HOME, right?
Also include dir is not versioned. See at
/usr/lib/python2.6/distutils/command/install.py:
'unix_prefix': {
'purelib': '$base/lib/python$py_version_short/site-packages',
'platlib': '$platbase/lib/python$py_version_short/site-packages',
'headers': '$base/include/python$py_version_short/$dist_name',
'scripts': '$base/bin',
'data' : '$base',
},
'unix_home': {
'purelib': '$base/lib/python',
'platlib': '$base/lib/python',
'headers': '$base/include/python/$dist_name',
'scripts': '$base/bin',
'data' : '$base',
},
Never mind, in our case we are just installing a platlib. No headers by now.
Notice also that here the $platbase appears again in contrast to $base.
The variety of schemas is quite crazy and covering all of them is insane, but
i found the home one particularly convenient for development without doing
sudo all the time or worrying about installed python versions, so i would love
having a LOCAL_PYTHON_INSTALL flag or the like for that.
David.