Produces errors in wasm builds - we want to be able to load the wrapper first and all other dependencies should be pluggable. But loading wrapper first failed, because it depended on the kernels. Loading kernels first would also fail, since OCCT kernel is using using some symbols from core (`ifcopenshell::exception`) and in wasm they have to be resolved all during `dlopen`.
Caused errors like so:
```
Traceback (most recent call last):
File "/__w/IfcOpenShell/IfcOpenShell/build/Linux/x86_64/install/python-3.13.6/lib/python3.13/site-packages/ifcopenshell/__init__.py", line 87, in <module>
from . import ifcopenshell_wrapper
File "/__w/IfcOpenShell/IfcOpenShell/build/Linux/x86_64/install/python-3.13.6/lib/python3.13/site-packages/ifcopenshell/ifcopenshell_wrapper.py", line 10, in <module>
from . import _ifcopenshell_wrapper
ImportError: libifcopenshell.geometry.writer.so: cannot open shared object file: No such file or directory
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "<string>", line 1, in <module>
import inspect, ifcopenshell; print(inspect.getfile(ifcopenshell))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/__w/IfcOpenShell/IfcOpenShell/build/Linux/x86_64/install/python-3.13.6/lib/python3.13/site-packages/ifcopenshell/__init__.py", line 89, in <module>
raise ImportError("IfcOpenShell not built for '%s' (%s)" % (python_distribution, e)) from e
ImportError: IfcOpenShell not built for 'linux/64bit/python3.13' (libifcopenshell.geometry.writer.so: cannot open shared object file: No such file or directory)
```
Three coupled fixes that close the macOS bring-up loop:
## 1. ifcwrap: fix INSTALL_RPATH on Apple
The ifcopenshell_wrapper Python module had `INSTALL_RPATH "$ORIGIN"` set
for "NOT WIN32 AND NOT WASM_BUILD" — but `$ORIGIN` is a Linux ld.so
placeholder, not a macOS dyld one. macOS dyld doesn't expand it; it
bakes the literal string `$ORIGIN` into LC_RPATH, which resolves to
nothing at runtime. The wrapper's hard-link `@rpath/ifcopenshell
.document.rdb.dylib` then fails to load even though INSTALL(TARGETS …
LIBRARY DESTINATION "${python_package_dir}/ifcopenshell") above had
already dropped the plug-in dylib right next to the wrapper.
Split the rpath assignment: `@loader_path` on Apple (the dyld
equivalent of `$ORIGIN`), `$ORIGIN` elsewhere.
This is what b0ef47819 (the build_osx IFCOS_BUILD_PYTHON_WRAPPER=off
gate) was working around. The gate is removed below.
## 2. ifcviewer-minimal: stage IfcOpenShell + wgpu_native into the .app
IfcViewerMinimal.app was building on macOS via the cmake
`BUILD_BONSAIVIEWER → BUILD_BONSAIVIEWER_WGPU` promotion, but had no
bundle staging — Contents/Frameworks/ only contained the Qt
frameworks macdeployqt deposited, so the .app would refuse to start
("Library not loaded: @rpath/libwgpu_native.dylib").
Mirror what src/bonsaiviewer/CMakeLists.txt does for BonsaiViewer.app:
* Set INSTALL_RPATH to `@executable_path/../Frameworks` so the exe
knows where to look for @rpath/* deps.
* install(FILES) libwgpu_native.dylib into the bundle's Frameworks/
(globbed from WGPU_NATIVE_LIB_DIR rather than hard-coded so it
covers any future versioned name).
* install(CODE) staging block that copies every `*.dylib` from
<prefix>/lib/ into the bundle's Frameworks/, excluding the
geometry-writer plug-ins (same EXCLUDE regex as BonsaiViewer.app —
viewer doesn't need OBJ/glTF/DAE/STP/IGS/SVG/TTL export converters).
Same long-form rationale + caveats apply (macdeployqt doesn't follow
non-Qt @rpath deps, lib-prefixed core libs vs ifcopenshell.* plug-in
naming split, Linux's equivalent lives in build_rocky.yml workflow
bash via patchelf + stage_runtime_payload). See src/bonsaiviewer/
CMakeLists.txt for the full version.
## 3. build_osx.yml: drop IFCOS_BUILD_PYTHON_WRAPPER=off
With (1) fixed, the Python wrapper smoke test should pass again. The
gate goes away; the comment block in build_osx.yml is replaced with a
short note pointing at the ifcwrap rpath fix as the underlying change
that re-enables this.
Together, (1)+(2)+(3) close the standalone IfcViewerMinimal-on-macOS
gap (task #43) and re-enable IfcOpenShell-Python on the macOS arm64 CI.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Next to `EXPORTED_FUNCTIONS` and avoid possible issues with pyodide in the future (pyodide is using `SIDE_MODULE=1`, but currently not providing it libraries of type `MODULE`, only for shared ones).
To fix 1k warnings running in cmake 3.30+
The new policy is that cmake is normalizing destination paths in `install` and warns if normalization has any effect on them. In our case paths after normalization should be fine, so switching it to `NEW`.
Andrej730