Return independent geometry copies with unique ownership, preserve parent lifetimes, and teach the Python wrapper to own derived results. Keep serializer inputs non-owning and replace Collada's deferred object with copied triangulation elements.\n\nGenerated with the assistance of an AI coding tool.
The optional adaptor element list was never assigned, so simplify IfcConvert to use its geometry iterator unconditionally.
Generated with the assistance of an AI coding tool.
Rename header-scope aliases, enums, and helper types while retaining descriptive names where dropping the suffix would create a collision.
Generated with the assistance of an AI coding tool.
Update the stale pointer-form example and pass the IFC file required by the current serialization API.
Generated with the assistance of an AI coding tool.
Apply the rename manifest, normalize serializer filenames to the classes they define, and update includes and CMake source lists.
Generated with the assistance of an AI coding tool.
To fix wrapper depending on `ifcopenshell.geometry.kernel.opencascade.so` plugin, which breaks wasm module import (wrapper imported first and it fails because occt kernel isn't loaded yet and loading kernel first since it needs some symbols from the wrapper).
`geometry_serializer` seems to need `OpenCascadeConversionResult.h` from the kernel just to be able to refer to structs (`ConversionResultShape`, `OpenCascadeShape`) and include with relative path already allows it.
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`.
rocks_db_file_storage already exposes a `g|`-prefixed guid -> instance
name map, but RocksDbSerializer never populated it, so by_guid() on a
converted file always threw.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Thomas Krijnen