Valloric / ycmd / 1929
85%
master: 94%

LAST BUILD BRANCH: python-completer-log-level
DEFAULT BRANCH: master
Ran
Jobs 1
Files 40
Run time 2s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
1929

push

travis-ci

homu 
Auto merge of #481 - micbou:find-python-libs, r=micbou

[READY] Do not rely on CMake to find Python libraries

### Problem

CMake is not able to find the Python libraries from `pyenv`. We can observe this on Travis. If we look at the build output of the Python 2.6 run on Linux, we have the following line during the CMake configuration:
```sh
-- Found PythonLibs: /usr/lib/libpython2.7.so (found suitable version "2.7.3", minimum required is "2.6")
```
which, in addition to be the wrong version, is the system library instead of the `pyenv` one. We confirm this by inspecting the `ycm_core.so` library from the build:
```sh
$ ldd ycm_core.so | grep python
libpython2.7.so.1.0 => /usr/lib/libpython2.7.so.1.0 (0x00007f0521fa1000)
```
Same issue with the Python 2.7 and 3.3 Linux runs although the library version is correct in these cases.
In the Travis configuration file, there is this comment:

> This is because stupid cmake 2.8.11 has a bug preventing it from finding the pyenv pythons (ostensibly; I haven't checked, but online reports say the issue is gone with cmake 3.4).

I tried with CMake 3.5.1 (3.5.2 is the last version) and it is still not working.

That's not all. In some situations, CMake find the wrong Python system libraries (see [this workaround on AppVeyor](https://github.com/Valloric/ycmd/blob/master/ci/appveyor/appveyor_install.bat#L36)) or cannot find them at all (see [this post on ycm-users](https://groups.google.com/forum/#!searchin/ycm-users/windows$20cmake/ycm-users/e6K-grbeUMw/0kzwtAaYCQAJ)).

### Solution

From this, it is clear that we cannot rely on CMake to find the Python libraries. We need to find them in the `build.py` script and pass the `PYTHON_LIBRARY` and `PYTHON_INCLUDE_DIR` parameters to CMake, like we already do for OS X.
This is implemented by creating a `FindPythonLibraries` function for each supported platform: Linux, OS X, and Windows. For OS X, we are keeping the logic from `CustomPythonCmakeArgs` except that we are dropping support for system Python 2.6. For Linux, we need to use the `ldconfig` tool to find the system Python library on some distributions (e.g. Ubuntu) because it is not installed in its standard location. For Windows, it is straightforward. In all cases, we assume that the Python running the script is the one that will be used to build the library.

This PR also fixes an important issue. When building the ycmd library with Clang support and linking it to a non-system Python libray, the dynamic linker will not be able to find the Python library:
```sh
$ ldd ycm_core.so | grep python
libpython3.4m.so.1.0 => not found
$ objdump -x ycm_core.so | grep RPATH
RPATH                $ORIGIN
```
This is solved by setting the `CMAKE_INSTALL_RPATH_USE_LINK_PATH` option to true (see [this wiki page](https://cmake.org/Wiki/CMake_RPATH_handling) for details on the option):
```
> ldd ycm_core.so | grep python
libpython3.4m.so.1.0 => /home/micbou/.pyenv/versions/3.4.4/lib/libpython3.4m.so.1.0 (0x00007f9fb6472000)
> objdump -x ycm_core.so | grep RPATH
RPATH                $ORIGIN:/home/micbou/.pyenv/versions/3.4.4/lib
```

Closes #196 (we don't care about the Python interpreter when building the ycmd library).
Fixes #479.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/ycmd/481)
<!-- Reviewable:end -->

3061 of 3603 relevant lines covered (84.96%)

0.85 hits per line

Jobs
ID Job ID Ran Files Coverage
1 1929.1 (USE_CLANG_COMPLETER=true YCMD_PYTHON_VERSION=2.7 COVERAGE=true) 0
84.96
 Travis Job 1929.1
Source Files on build 1929
Detailed source file information is not available for this build.