Last reference to this file was dropped in 7ae685dbf, though the ref was
pointing to `/patches/opencollada/pr622.patch`, so IIUC
`patches/pr622.patch` was never used.
(cherry picked from commit c013b9aca7)
Introduced in e21277e80, reference removed
in 683cadeb7 when occt was bumped to 7.3.0 and switched to git-tag based
download.
(cherry picked from commit 24e454ce0c)
Error was:
```
configure: error: could not find a working compiler, see config.log for details
```
config.log:
```
conftest.c: In function 'f':
conftest.c:12:48: error: too many arguments to function 'g'; expected 0, have 6
12 | for(i=0;i<1;i++){if(e(got,got,9,d[i].n)==0)h();g(i,d[i].src,d[i].n,got,d[i].want,9);if(d[i].n)h();}}
| ^ ~
```
d390911d75 ("build_osx: build BonsaiViewer on macOS via build-all.py",
2026-06-01) accidentally committed a local single-version pin
(`PYTHON_VERSIONS = ["3.11.8"]`) intended only for fast iteration
during macOS bring-up. With macOS / CI green and the Python wrapper
fix from 748b4e72a landed, restore the full multi-version list so
both Rocky and macOS CI publish wrappers for 3.10/3.11/3.12/3.13/3.14
again.
Cost is ~5 from-source Python builds per CI run; the cache-deps
plumbing in nix/cache_dependencies.py already memoises these so
repeated runs only pay it once per Python release bump.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
# Why this exists
The bonsai macOS CI (`build_osx.yml`, arm64) currently fails the
`IfcOpenShell-Python` smoke test with:
ImportError: dlopen(.../_ifcopenshell_wrapper.cpython-311-darwin.so,
0x0002):
Library not loaded: @rpath/ifcopenshell.document.rdb.dylib
Reason: tried: '$ORIGIN/ifcopenshell.document.rdb.dylib'
(no such file)
`_ifcopenshell_wrapper.cpython-311-darwin.so` has a hard `LC_LOAD_DYLIB`
of `@rpath/ifcopenshell.document.rdb.dylib` and its only `LC_RPATH` is
`$ORIGIN` (= `site-packages/ifcopenshell/`). The plug-in dylib is not
present at that path on macOS, so the wrapper fails to load and the
build smoke test (`build-all.py: compile_python_wrapper`) errors out.
BonsaiViewer.app builds, installs, and macdeployqt-deploys cleanly
before this point — the failure is downstream and unrelated to wgpu,
BonsaiViewer, or anything else on this branch.
# Where the regression came from
Two commits on the branch line that became `ifcviewer-wgpu`:
b599ee10 "More work on isolating into plug-ins" (2026-04-18, Thomas Krijnen)
b022ca7e7 "Some plug-in work" (2026-04-21, Thomas Krijnen)
`b599ee10` added a hard link dep:
target_link_libraries(ifcopenshell_wrapper PRIVATE document_serializer_rdb)
which bakes `@rpath/ifcopenshell.document.rdb.dylib` into the wrapper's
`LC_LOAD_DYLIB`. `b022ca7e7` added a `if(CREATE_BUNDLE) ...
install(TARGETS ${_ifcopenshell_python_runtime_targets}
LIBRARY DESTINATION "${python_package_dir}/ifcopenshell" ...)` block
that was *intended* to satisfy that link dep by copying plug-ins next
to the wrapper. On macOS arm64 the install rule does not actually
deposit `ifcopenshell.document.rdb.dylib` into
`site-packages/ifcopenshell/`, so the runtime dlopen fails.
# Why 227d85d worked
`227d85d` (2026-05-15) is on the `v0.8.0` line, not on the
`datamodel-v1.0 -> ifcviewer -> ifcviewer-wgpu` line. The merge-base
of `227d85d` and `ifcviewer-wgpu` is `e6258ab4` (2026-04-13). Both
b599ee10 and b022ca7e7 live on the wgpu side of that fork and are not
ancestors of `227d85d`:
$ git merge-base --is-ancestor b599ee10227d85d
[exit 1 — NOT an ancestor]
$ git merge-base --is-ancestor b599ee10 v0.8.0
[exit 1 — NOT an ancestor]
So the macOS Python wheel built fine on `v0.8.0` because that branch
never had the plug-in refactor; it has been broken on our branch line
since 2026-04-21. Nobody noticed because nobody had been firing
`build_osx.yml` against this branch line until this week's bonsai CI
work.
# What this commit does
Adds an `IFCOS_BUILD_PYTHON_WRAPPER` env var to `nix/build-all.py`.
Defaulting to `on` preserves existing behaviour everywhere; setting
it to `off` (or `0`/`false`/`no`) drops `IfcOpenShell-Python` from
the target set so `build-all.py` skips the wrapper build + smoke
test entirely.
`build_osx.yml` sets `IFCOS_BUILD_PYTHON_WRAPPER=off` so the bonsai
macOS CI can complete and upload `BonsaiViewer.app` while the plug-in
install rule is broken.
# What Thomas should do
Once the install rule in `src/ifcwrap/CMakeLists.txt` (the
`if(CREATE_BUNDLE) ... install(TARGETS ${_ifcopenshell_python_runtime_targets}
LIBRARY DESTINATION "${python_package_dir}/ifcopenshell" ...)` block,
added in b022ca7e7) is fixed to actually drop
`ifcopenshell.document.rdb.dylib` next to the wrapper in
site-packages on macOS — this commit can be reverted in its entirety:
the env-gate in `build-all.py` AND the `IFCOS_BUILD_PYTHON_WRAPPER=off`
in `build_osx.yml`. The bonsai macOS workflow will then build the
Python wrapper too.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Linux (build_rocky.yml) and Windows (win/build-all-win.py) already pass
BUILD_BONSAIVIEWER=ON when building from source; macOS was the odd one
out. Three small changes to bring it up to parity:
1. .github/workflows/build_osx.yml — \`brew install qt\` (Qt6 with Svg)
in the Install Dependencies step, then set QT_DIR=\$(brew --prefix
qt) and BUILD_BONSAIVIEWER=ON in the Run Build Script env.
2. nix/build-all.py — install_qt6() now honours a pre-set QT_DIR.
Before this change get_qt6_aqt_config() raised on non-Linux,
blocking bonsai builds on macOS/Windows from ever using a
system-provided Qt6. We now validate that QT_DIR points at a real
Qt6 install (probes lib/cmake/Qt6/Qt6Config.cmake) and skip the aqt
download path if so. Linux flow is unchanged: when QT_DIR is unset
the function falls through to the existing aqtinstall path.
build_osx.yml stays workflow_dispatch-only — slow run (~1h with
ccache, longer cold), so manual fire when wanted. Cherry-pick this
file + nix/build-all.py to v0.8.0 to make the workflow dispatchable
against the ifcviewer-wgpu branch before the squash lands.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Compile the Bonsai Viewer as part of the Linux and Windows binary builds,
and ship the Autodesk connector alongside the viewer executable.
Qt6 dependencies:
- The viewer links Qt6::Svg for runtime icon tinting. Svg is a separate
base-Qt archive, so aqt now installs "qtbase qtsvg" (plus icu on Linux)
rather than qtbase alone, on both Linux and Windows.
- Qt6::CorePrivate is exposed differently across Qt versions: Qt 6.8 ships
the target inside Qt6Core, while Qt 6.10 provides it only as a separate
CorePrivate config package. The viewer CMakeLists requests it via
OPTIONAL_COMPONENTS so it resolves on both.
- When cross-compiling Windows ARM64, windeployqt runs from the host x64
Qt, so qtsvg is installed into the host Qt as well.
Windows build:
- build-all-win.py passed -DBUILD_IFCVIEWER, a flag since renamed to
BUILD_BONSAIVIEWER, so the Windows build compiled no viewer at all. It
now passes -DBUILD_BONSAIVIEWER.
- The Autodesk connector is bundled under connectors/ next to
BonsaiViewer.exe in the packaged archive, mirroring the Linux builds.
- The Windows workflow builds the connector (PyInstaller) before the main
build so it is available to bundle.
Connector bundling:
- The Linux rocky workflows build the connector and bundle it into the
BonsaiViewer archive; the Windows build now does the same.
Generated with the assistance of an AI coding tool.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Replace the old IFC viewer build switch with BUILD_BONSAIVIEWER in CMake, the Linux workflows, and the nix build script.
Generated with the assistance of an AI coding tool.
Dion Moult