This one removes the i-files hacks by making the parts* and utils libraries load the main _simavr.so dynamically. This one is bit tricky because:
The Python Extension naming convention for shared libs doesn't follow the usually lib<lib>.so pattern.
The _simavr.so is not installed in the usuall paths included in the LD_LIBRARAY_PATH.
In Py3 the lib extension is not plain .so but it includes platform and python version identifiers (to suport ABI I guess). For example _simavr.cpython-35m-x86_64-linux-gnu.so.
So in summary to get around the above it involves:
Setting RUNPATH/RPATH to the $ORIGIN for the all libraries linking the main _simavr.so. So when the dynamic linker searches for the _simavr.so it will also check the folder where the library being linked is located. This works because all the libraries are in the same folder.
Explicitly setting SO_NAME on the _simavr.so. That way the NEEDED value of the other libraries only include the _simavr.so (or for example _simavr.cpython-35m-x86_64-linux-gnu.so on Py3) without the file path (like build/lib.linux-x86_64-3.6/pysimavr/swig).
It might feel little bit like replacing one hack with another :-) But on the other hand it sill keeps some degree of modularity without changing the distribution process completly. And it enables C++ required for the callbacks in the wrapper files. Where the old hack means some parts of the simavr C would have to be compile using C++ compiler.
Coverage decreased (-0.1%) to 78.649% when pulling 79543010f0dd6908df7f60875607ce8a4970151a on Premik:unhack into 7b362c5bdb1bf694909d21ce53a407d894bacda8 on ponty:master.
Coverage decreased (-0.2%) to 78.588% when pulling b56e15f7febd8168c8640b31800536b033c68a27 on Premik:unhack into 7b362c5bdb1bf694909d21ce53a407d894bacda8 on ponty:master.
Coverage decreased (-0.2%) to 78.588% when pulling b56e15f7febd8168c8640b31800536b033c68a27 on Premik:unhack into 7b362c5bdb1bf694909d21ce53a407d894bacda8 on ponty:master.
This one removes the i-files hacks by making the parts* and utils libraries load the main _simavr.so dynamically. This one is bit tricky because:
lib<lib>.so
pattern._simavr.cpython-35m-x86_64-linux-gnu.so
.So in summary to get around the above it involves:
_simavr.cpython-35m-x86_64-linux-gnu.so
on Py3) without the file path (likebuild/lib.linux-x86_64-3.6/pysimavr/swig
).It might feel little bit like replacing one hack with another :-) But on the other hand it sill keeps some degree of modularity without changing the distribution process completly. And it enables C++ required for the callbacks in the wrapper files. Where the old hack means some parts of the simavr C would have to be compile using C++ compiler.