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
Currently, the client application has to guess what platform it is targeting, which is tricky when we may be cross compiling, such that the host is different than target. For example tiledbsoma has this:
Where we are supposed to set CMAKE_OSX_ARCHITECTURES manually when cross compiling. And then some more heuristics when building the R package. This is painful and error prone. If you just ship libtiledb as universal binaries you can get rid of all that, one library that will just work any macos hardware, even with cross compiling.
The text was updated successfully, but these errors were encountered:
Thanks for submitting the PR @jeroen and helping us with your build expertise. For TileDB as a whole there may be other issues at hand beyond the use by CRAN (which is the primary use case here) so the build team will take a look but as a first reaction a simplification and robustifcation seems welcome.
Currently you are releasing separate binaries for macos x86_64 and arm64, for example:
It is very easy on macos to merge two libraries into "univeral binaries", for example:
The resulting
libtiledb.dylib
contains both libs and can be linked on either architecture:Currently, the client application has to guess what platform it is targeting, which is tricky when we may be cross compiling, such that the host is different than target. For example tiledbsoma has this:
Where we are supposed to set
CMAKE_OSX_ARCHITECTURES
manually when cross compiling. And then some more heuristics when building the R package. This is painful and error prone. If you just ship libtiledb as universal binaries you can get rid of all that, one library that will just work any macos hardware, even with cross compiling.The text was updated successfully, but these errors were encountered: