Pybind issue

[syncle]

I notice that cmake 3.6 tool-chain generates py3d instead of py3d.so after compilation.
This affects python scripts. They don't recognize py3d library.

For example:

> python
>>> from py3d import *
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named py3d

But if I change the name, it works

> mv py3d py3d.so
> python
>>> from py3d import *
(no error)

This issue comes with MacOSX Sierra, Cmake 3.6, Mac Native Python 2.7.
Windows + VisualStudio2015 seems to fine.
We may need to change CMakeList.txt file or get some information from Pybind to fix this issue.

[syncle]

I tried Pybind Cmake example and was able to get cmake_example.so.

[syncle]

Still cannot figure it out how to solve this.

In addition to the file extension problem, there is a python version issue when I am using anaconda. Anaconda sets custom python environment version (e.g. version 1) if I type python, and CMake exploits system path (e.g. version 2) to compile pybind11. The two versions may not match.

As a result, compiled Python package is not importable from terminal.

To make it work, I have to find out which python version is used for compilation, and set conda environment to that version to execute Open3D python script.

The solution would be make CMake to force current python environment not to try to use system path.

[qianyizh]

There is a paragraph in the documents I wrote.
I copied some of the it from the pybind11 document:

Python binding
We use pybind11 to build the Python binding. It tries to automatically detect the installed version of Python and link against that. When this fails, or when there are multiple versions of Python and it finds the wrong one, delete CMakeCache.txt and then invoke CMake as follows:

cmake -DPYTHON_EXECUTABLE:FILEPATH= ../src
If you do not want Python binding, turn off the compilation options Open3D_BUILD_PYTHON_BINDING and Open3D_BUILD_PYTHON_BINDING_TESTS.

[syncle]

This command worked for me. I am using anaconda3 for Python 3.x, system default is Python 2.7

cmake -DPYTHON_EXECUTABLE:FILEPATH=/home/account_id/anaconda3/bin/ 
-DPYTHON_LIBRARY='/home/account_id/anaconda3/lib/libpython3.so' ../src

The point is I had to identify DPYTHON_EXECUTABLE and DPYTHON_LIBRARY for successful compilation.

But I still got py3d after compilation, not desired py3d.so. After I compile python binding I manually rename py3d to py3d.so. I think this is an issue for recent cmake versions (my cmake is 3.8.2). It was not happened to @qianyizh with cmake 3.2

[qianyizh]

Addressed in #82

[qianyizh]

I just came across the exact same issue on my OSX with Anaconda 3.6. The above workaround fixed it.
Also I read this interesting post:
pybind/pybind11#99

I enjoyed reading this quote:

After reading through the numerous related bug reports involving homebrew, Python, and CMake, especially Homebrew/legacy-homebrew#25118 and http://www.itk.org/Bug/view.php?id=14809 , which you have contributed to, I developed a strong headache and stopped. I especially enjoyed this four year-old quote: "Basically, CMake clings to Frameworks like a drowning sailor on OSX" from Homebrew/legacy-homebrew#10393 (comment) . The issue persists in CMake 3.5.0-rc1.

Anyways, it is definitely not a problem of Open3D, and probably not a problem of pybind11, but likely a problem of CMake. Pybind11 marked it as WONTFIX. Likewise in Open3D.

[qianyizh]

May worth adding

cmake -DPYTHON_EXECUTABLE:FILEPATH=/home/account_id/anaconda3/bin/python 
-DPYTHON_LIBRARY='/home/account_id/anaconda3/lib/libpython3.so' ../src

To our document though.

[qianyizh]

This is the command I eventually used to make anaconda with customized env work:

cmake -DPYTHON_LIBRARY=/Users/qianyizh/anaconda/envs/py36/lib/libpython3.6m.dylib
-DPYTHON_INCLUDE_DIR=/Users/qianyizh/anaconda/envs/py36/include/python3.6m
-DPYTHON_EXECUTABLE:FILEPATH=/Users/qianyizh/anaconda/envs/py36/bin/python3.6m
../src