Explore shared lib creation

[molpopgen]

We should test the link in the answer here.

If this works, it'll probably improve build times by a lot.

Main question: does pip install still work?

To-do:

• Test with dummy repo and report back here...

[molpopgen]

This works just fine on Linux. There are some questions re: the setup.py in that answer, but that should be easy to sort out. As always, gotta test independently on macOS.

[molpopgen]

This would be a great way to solve #625!

[molpopgen]

There are some questions re: the setup.py in that answer,

Aha: https://nehckl0.medium.com/creating-relocatable-linux-executables-by-setting-rpath-with-origin-45de573a2e98

[molpopgen]

Doing this right also means providing a Python API to find the shared lib, as we'll end up moving a good bit of the C++ back-end to the shared lib. We'll also want to enable LTO by default.

[molpopgen]

Relevant to macOS: https://gitlab.kitware.com/cmake/community/-/wikis/doc/cmake/RPATH-handling

[molpopgen]

It is not obvious what auditwheel/delocate will do here. For example, they copy dependent libs to a new location. If we install our shared lib as package data, then it is possible that a plugin causes multiple versions of a symbol to be present at run time.

[molpopgen]

It is not obvious what auditwheel/delocate will do here.

All is fine on Linux! (Still requires #683 for stress testing, tho.)

[molpopgen]

All is fine on Linux! (Still requires #683 for stress testing, tho.)

There is a problem, actually. If the shared lib also links to GSL, then that dependency is not relocated by auditwheel.

[molpopgen]

If the shared lib also links to GSL, then that dependency is not relocated by auditwheel.

A partial solution is to build the shared lib in another directory, so that it looks "external". This relocates the shared lib, which is great for run time, but makes it difficult/impossible to have plug ins link to it.

[molpopgen]

If the shared lib also links to GSL, then that dependency is not relocated by auditwheel.

A partial solution is to build the shared lib in another directory, so that it looks "external". This relocates the shared lib, which is great for run time, but makes it difficult/impossible to have plug ins link to it.

pypa/auditwheel#136 needs a solution before we can proceed.

[molpopgen]

We can close this. The best solution for now is the static lib approach introduced in 0.18.0