CGAL never runs `find_package` for `Boost`, `GMP` or `MPFR` during its configuration and never hardcodes their paths to the generated configs. So providing them have no effect. It's also can be confirmed by `build-deps.cmd` on Windows running all this time without the most of these args. Though it was settings `BOOST_ROOT` but it had no effect too.
Probably it's some kind of artifact from CGAL past when it's used to be non-header-only library.
Caching of version path was introduced in c5f6d47, awhile ago, removing it, since all new installations are already using the cache instead of this default fallback.
`robocopy` line was an artifact from old layout.
It was only needed to set `PYTHON_INSTALLER` correctly, but
`PYTHON_INSTALLER` is actually only used when arch is not x64/arm64,
exactly the only cases when `PYTHON_AMD64_POSTFIX` is set.
It's dating back to the original implementation in 5c0eb05, it was
needed to avoid rebuilding opencollada. Not needed anymore since
previous installations are now recognized.
We mark some dependency installations using empty `.release/debug_installation` files to support coexisting release/debug installations, which is needed on Windows to be able to easily switch between Release/Debug builds of IfcOpenShell and avoiding conflicts when different binaries are using different debubg/non-debug runtimes.
It was introduced in 517ba237f and `mark_based_on_artifacts` was pre-existing installations based on the found artifacts, all new installations were not relying on this for marking. Since it's been some time, dropping this workaround.
Introduced in 2e35b07 when moving to github releases, removing it since
it's been 20 months already.
Added temporary clean up step to remove previous installation.
Resolves the warnings below:
```
CMake Deprecation Warning at CMakeLists.txt:207 (message):
Use SQLite3_INCLUDE_DIR instead of SQLITE3_INCLUDE_DIR
CMake Deprecation Warning at CMakeLists.txt:211 (message):
Use SQLite3_LIBRARY instead of SQLITE3_LIBRARY
```
It was introduced a (very) long time ago (c7bf03e), was barely changed since then and seems unused by now.
Apparently it was used mainly to get installation's Python to PATH (`set PATH=%PYTHONHOME%;%PATH%`). It was also setting and env variables based on the cache as a side effect.
If needed, we'll be able reintroduce it later, delegating most of the logic to Python.
`TARGET_ARCH` has exactly the same values as `VS_PLATFORM` - "x64", "ARM", "ARM64") except it has `x86` instead of `Win32`, but this value is never actually used, so both variables end up using interchangeably, making code harder to reason about - you needed to remember that they're exactly the same except the case when the variable is passed directly to VS (either through `cmake -A` or some `msbuild` command), then user must use `VS_PLATFORM`. So we might just use one variable always.
`START` is set to `0` for "amd64" / "x64" and `1` in all other cases, effectively just skipping `GENERATORS[0]` in case when "amd64" or "x64" is present.
Which is now useless, since `GENERATORS[0]` doesn't exist anymore.
They were added awhile ago in 67666ed for overcoming some win32 issues, which is not around anymore.
And now `VS_HOST` is never set (and therefore `VS_TOOLSET_HOST` is always empty too) and likely to be never used.
Runtime plugins are canonically named `ifcopenshell_<kind>_<name>` (decorated_basename() in src/plugin/plugin.cpp, and the OUTPUT_NAME properties of the plugin targets), but the archive collection filtered on the dotted `ifcopenshell.` prefix, which matches only the core shared libraries. Every load-by-name plugin was therefore silently dropped from every win64 / win-arm64 zip.
Accept both prefixes, and extend the geometry-writer exclusion to the underscore form so the per-schema writers keep their existing Python-package-only treatment.
Fixes#9301
* Modifications to build C++ with Visual Studio 2026 and the v145 toolset.
* Fixes linker settings for rocksdb for Debug and Release builds
* module is a C++ 20 keyword. Explicitly stating namespace allows cpp20 projects to build against the library
* Fixes crash when initializing an object with the initialize function when some of the attributes are empty, {}, or omitted, std::nullopt
* cleanup for vs2026 v145 toolset per @aothms review
* Fixes bug, IfcCurveSegment.setStartLength was setSegmentLength in alignment_helper.cpp
* Bumps boost to 1.92
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>
Andrej730