You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am working on a library that uses CMake as build generator, and wraps a third party library that distributes a pre-compiled shared library. My current approach to package this has been to call install(...) within CMake on the components I need from the third party library, and make sure they are placed in my wheel appropriately.
However, by installing the third party library in this manner (let's call the third party library "foo") I must then exclude it from the auditwheel / delocate / delvewheel steps, either with the exclude commands or --ignore-in-wheel for delvewheel
Unfortunately, another Python package may choose to distribute libfoo, and with a version that is not ABI compatible. At runtime, if the other Python package is loaded first, the linker will use that version instead of what has been installed in my wheel. On Unix systems, I am able to avoid this issue with RPATH linkage, but on Windows I think I really need to figure out a way to get delvewheel to work
Is there a way within cibuildwheel that I can pass the path of the source / build tree where my subproject is located to any of the wheel repair commands, so that they can find the library of interest?
Description
I am working on a library that uses CMake as build generator, and wraps a third party library that distributes a pre-compiled shared library. My current approach to package this has been to call
install(...)
within CMake on the components I need from the third party library, and make sure they are placed in my wheel appropriately.However, by installing the third party library in this manner (let's call the third party library "foo") I must then exclude it from the auditwheel / delocate / delvewheel steps, either with the
exclude
commands or--ignore-in-wheel
for delvewheelUnfortunately, another Python package may choose to distribute
libfoo
, and with a version that is not ABI compatible. At runtime, if the other Python package is loaded first, the linker will use that version instead of what has been installed in my wheel. On Unix systems, I am able to avoid this issue with RPATH linkage, but on Windows I think I really need to figure out a way to get delvewheel to workIs there a way within cibuildwheel that I can pass the path of the source / build tree where my subproject is located to any of the wheel repair commands, so that they can find the library of interest?
In case it is of use, here is the actual library I am working on https://github.com/innobi/pantab/tree/531566c
Build log
No response
CI config
https://github.com/innobi/pantab/blob/531566c23b3f5208003a6a7e5d48fa519b38dfd5/.github/workflows/unit-test.yml
The text was updated successfully, but these errors were encountered: