Split C++ code in 2 separate shared libraries

[tristan0x]

Remove Basalt_BUILD_PYTHON_PACKAGE CMake option to choose if
the pure C++ library has to be built or the Python bindings.

Now CMake builds 2 shared libraries:

• basalt which contain pure C++ code.
• _basalt: built by pybind11, and depends on the first.
  a dirty workaround is required in basalt/__init__.py so that
  Python bindings can find the pure C++ code at runtime.

[ferdonline]

I like such kind of separation.
Maybe one suggestion would be to require linking with a static version so you only have one final library and avoid doing the python workaround.

[tristan0x]

Thank you @ferdonline
I followed your advice, but used add_library(name OBJECT) instead of creating a static library, which just build a set of object files, that you can then reused elsewhere.

I still need to prevent building the other shared library (the one without bindings) during python setup.py build otherwise it is grabbed by distutils.
Thanks!

[ferdonline]

I still need to prevent building the other shared library (the one without bindings) during python setup.py build otherwise it is grabbed by distutils.

Some python packages put a leading underscore in the lib name if it's not expected to be used standalone. Maybe that's the case here?

[tristan0x]

I still need to prevent building the other shared library (the one without bindings) during python setup.py build otherwise it is grabbed by distutils.

Some python packages put a leading underscore in the lib name if it's not expected to be used standalone. Maybe that's the case here?

Yes this module provides both Python and native code.
For instance here is the content of the wheel if I simply run the all make target:

 _basalt.cpython-36m-x86_64-linux-gnu.so
 libbasalt.so
 basalt/__init__.py
 basalt-0.0.1.dist-info/METADATA
 basalt-0.0.1.dist-info/WHEEL
 basalt-0.0.1.dist-info/top_level.txt
 basalt-0.0.1.dist-info/RECORD

This libbasalt.so is not required anymore because everything is shipped in _basalt..so

But I am fine to execute a more precise make target in setup.py as building libbasalt.so does not make sense in this context.

[ferdonline]

I'm not following this very closely but I agree 100% with the separation of concepts and the new building rules.