The Python implementation of the Autodesk Forma connector
(bonsaiviewer_autodesk/) is deprecated. The Rust port that's been
maturing under src/bonsaiviewer-autodesk-rs/ is now the connector
and takes over the original folder name.
## File operations
* `git rm -r src/bonsaiviewer-autodesk` — drop the 18 tracked Python
source/test/packaging files. (~6.5k untracked build artefacts in
venv/build/dist/egg-info are removed too, but those were never in
the index.)
* `mv src/bonsaiviewer-autodesk-rs src/bonsaiviewer-autodesk` —
the Rust impl takes over the canonical folder name.
* `rm -rf src/bonsaiviewer-autodesk-rs-egui` — abandoned egui-based
experiment, never committed.
* `src/bonsaiviewer-autodesk/.gitignore` extended with `/dist` to
keep packaging output out of the index alongside the existing
`/target` rule.
The Rust binary in Cargo.toml already has `name = "bonsaiviewer-
autodesk"` and `connector.json`'s `exec` field already points at that
name — so the connector loader, build_viewer.sh symlink, and
win/build-all-win.py CONNECTOR_DIR all keep working without edits.
## Packaging shape preserved
`packaging/build.py` is rewritten to:
* shell out to `cargo build --release` instead of pyinstaller,
* copy the produced binary + connector.json into the same
`dist/autodesk/` layout the PyInstaller flow produced,
* zip into `dist/autodesk-<os>-<arch>.zip` with the same
naming pattern (CI artifact uploads keep working).
The Rust binary statically links its deps, so unlike PyInstaller
there's no `_internal/` directory — single executable inside
`dist/autodesk/`. Everything downstream (`build_viewer.sh` symlink,
`win/build-all-win.py collect_connector_files`, the zip step in
`build_rocky.yml`) only cares that `dist/autodesk/` exists, so the
on-disk contract is preserved.
Verified locally: `python3 src/bonsaiviewer-autodesk/packaging/build.py`
produces `dist/autodesk/{bonsaiviewer-autodesk, connector.json}`
(3.9 MB stripped ELF) and `dist/autodesk-linux-x86_64.zip` (~1.5 MB
compressed).
## CI updates
* `.github/workflows/build_rocky.yml` and `build_rocky_arm.yml`:
drop the `pip install ".[build]"` step — `packaging/build.py` is
stdlib-only now, the cargo build wrapped inside it does the work.
* `.github/workflows/build_win.yml`: same — drop pip install,
packaging script handles cargo internally.
* `.github/workflows/build-bonsaiviewer-autodesk.yml`: full rewrite
of the dedicated connector test/build workflow. Replaces the
Python {3.11, 3.13} test matrix with `cargo fmt --check`,
`cargo clippy --all-targets -- -D warnings`, and `cargo test
--all-features`. The OS/arch build matrix is unchanged
(linux-x86_64, macos-arm64, macos-x86_64, windows-x86_64) but
installs a Rust toolchain via dtolnay/rust-toolchain@stable and
caches target/ via Swatinem/rust-cache.
`win/build-all-win.py` and `build_viewer.sh` are unchanged — they
only reference the `dist/autodesk/` path, which the new
`packaging/build.py` populates identically.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The Windows branch of the wgpu-native FetchContent block was
hardcoding the x86_64 archive name regardless of host arch — the
macOS and Linux branches already switch on
\`CMAKE_SYSTEM_PROCESSOR MATCHES "arm64|aarch64"\`, but Windows
didn't get the same treatment because the wgpu work was done on
x86_64 hosts.
Result on \`windows-11-arm\`: CMake downloaded
\`wgpu-windows-x86_64-msvc-release.zip\`, IfcViewerWgpu linked against
the x86_64 import library, and the final link of
IfcViewerWgpuMinimal/BonsaiViewer emitted ~60 unresolved \`wgpu*\`
externs because the import-lib symbols are x86_64-only.
Upstream wgpu-native v29.0.0.0 already publishes
\`wgpu-windows-aarch64-msvc-release.zip\` — switching on
\`CMAKE_SYSTEM_PROCESSOR\` so the right archive gets fetched is
sufficient.
Also restores the ARM64 row in \`.github/workflows/build_win.yml\`
that the prior commit dropped (the comment there was wrong; upstream
does ship the binary, our CMake just wasn't asking for it).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Bundles four portability fixes uncovered by manually firing the platform
workflows against this branch:
- WgpuOverlayRenderer.cpp: GCC 11 (Rocky manylinux runner) does not parse
a multi-line raw string inside `#define`. Converted
THICK_LINE_HELPERS_WGSL from a `#define` to a `static const char*` and
switched AXIS_WGSL / SECTION_WGSL / MARQUEE_WGSL to `std::string` so
they can concatenate at static-init time. Three call sites now pass
`.c_str()` to svFromCStr.
- bonsaiviewer/CMakeLists.txt: added BUNDLE DESTINATION to the install
rule (same fix already applied to IfcViewerWgpuMinimal). MACOSX_BUNDLE
targets fail at configure on macOS without it even when nobody runs
`make install`.
- build_osx.yml: dropped the x64 (Intel cross-compile) matrix row. The
runner is arm64 so `brew --prefix qt` returns the arm64 prefix; we'd
need a separate x86_64 Qt install under /usr/local to cross-build
BonsaiViewer. Revisit if Intel-Mac demand resurfaces.
- build_win.yml: dropped the ARM64 matrix row. wgpu-native does not ship
a Windows-ARM64 binary, so IfcViewerWgpu's link step fails with ~60
unresolved wgpu* externs. Re-enable when upstream publishes that
target.
Cherry-pick this commit to v0.8.0 so the workflow_dispatch buttons see
the dropped rows.
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>
Thomas Krijnen