Open LecrisUT opened 1 month ago
CMake strips RPaths that are outside the install tree. You probably need:
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH ON)
That will leave the proper $ORIGIN
rpaths and fix the issue above for macOS. I see Windows mentioned at https://cmake.org/cmake/help/latest/prop_tgt/INSTALL_RPATH.html, so worth trying this on Windows too.
CMAKE_INSTALL_RPATH_USE_LINK_PATH
relates to out-of-tree dependencies and it doesn't apply to the refactored code. Otherwise I am using INSTALL_RPATH
and it works on linux and in the macos issue can see that it is still there in Search path
error message. Does macos not support $origin
? One clue I've found is a commit that changed it to @loader_path
.
For windows it points to TARGET_RUNTIME_DLLS
genex, which might work for install(FILES)
I guess.
CMAKE_INSTALL_RPATH_USE_LINK_PATH
relates to out-of-tree dependencies and it doesn't apply to the refactored code. Otherwise I am usingINSTALL_RPATH
and it works on linux and in the macos issue can see that it is still there inSearch path
error message. Does macos not support$origin
? One clue I've found is a commit that changed it to@loader_path
.For windows it points to
TARGET_RUNTIME_DLLS
genex, which might work forinstall(FILES)
I guess.
In our project (https://github.com/mqt-core) we use the following snippet
if(APPLE)
set(BASEPOINT @loader_path)
else()
set(BASEPOINT $ORIGIN)
endif()
set(CMAKE_INSTALL_RPATH ${BASEPOINT} ${BASEPOINT}/${CMAKE_INSTALL_LIBDIR})
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
set(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
The BASEPOINT
is exactly for what you are alluding to above.
CMAKE_BUILD_WITH_INSTALL_RPATH
avoids a code signing issue on macOS when installing the libraries as part of the wheel.
As for the windows problems: you can emulate something similar to what delvewheel is doing and patch your __init__.py
import sys
# under Windows, make sure to add the appropriate DLL directory to the PATH
if sys.platform == "win32":
def _dll_patch() -> None:
"""Add the DLL directory to the PATH."""
import os
import sysconfig
from pathlib import Path
bin_dir = Path(sysconfig.get_paths()["purelib"]) / "mqt" / "core" / "bin"
os.add_dll_directory(str(bin_dir))
_dll_patch()
del _dll_patch
At least that's our current way of trying to make it work in https://github.com/cda-tum/mqt-core/pull/662
Awesome, thanks for sharing that. Let me try them out and I'll share my version as well for reference
Ok, here's my version which addresses various quirks. Some parts are due to having the C library be the main CMake recipe, but all sub-projects are independently buildable.
The last part I'm not fond of because it creates a copy of the .dll
file instead of making a symlink. Another caveat is that if the C/C++ library has other external dependencies, it would need RUNTIME_DEPENDENCIES
added, but I couldn't find a way to filter out the default system ones, e.g. libc
I have started to work on https://github.com/spglib/spglib/pull/520, where I redesign the build process to be more compatible with
audit-wheel
and make things simpler overall. The problems that I am trying to tackle there:pip install
environment (too fragile to allow standalonecmake --install
without populating.dist-info
metadata)INSTALL_RPATH
on the python bindings file pointing to$ORIGIN/${CMAKE_INSTALL_LIBDIR}
GNUInstallDirs
(except for the python bindings which point to.
), with the install prefix pointing to the python packageThat design works relatively well but I am hitting 2 issues:
INSTALL_RPATH
equivalent, and usually it relies on all the.dll
files being in the same folder, but this conflicts withGNUInstallDirs
where it would put them inbin
, but on the other hand, we need the python bindings to be under the path dictated byimport ...
. Is there a way to reconcile these? I was thinking maybe putting the python bindings under theGNUInstallDirs
structure as well, but that is not predictable since it would be${CMAKE_INSTALL_LIBDIR}
on unix, but${CMAKE_INSTALL_BINDIR}
on windowsrepair-wheel
commands are failing with rather cryptic issue: