TedToolkit.CppBindings.Occt.Generator 2026.9.15

TedToolkit.CppBindings.Occt.Generator

Generate matching C# and C++ OCCT bindings from installed headers and compiler-proved facts. This .NET 10 tool package supplies the OCCT provider for the reusable generation platform, not the ready-to-use Windows bindings.

The package is unreleased. Use a locally packed package or a repository project reference.

Generate sources

Install OCCT 8.0.1 in vcpkg's x64-windows triplet and set VCPKG_ROOT. The supported profile is Windows x64, MSVC ABI, a compatible Clang parser/probe, and CMake 3.28 or later.

using ModularPipelines;
using TedToolkit.CppBindings.Occt.Generator;

var output = new DirectoryInfo("output/generated");
var pipeline = await Pipeline.CreateBuilder()
    .AddOcctGenerators(new OcctGenerationOptions
    {
        DeclOptions = [new OcctDeclarationOptions("Geom2d_BSplineCurve")],
        CSharpFolder = output.CreateSubdirectory("csharp"),
        CppFolder = output.CreateSubdirectory("cpp"),
        NativeLibraryVersion = new Version(8, 0, 1),
    })
    .BuildAsync();
await pipeline.RunAsync();

Output roots must be dedicated and non-overlapping: validated preparation clears their old contents. Generation performs native compiler probes but does not build the final binding DLL. Compile cpp/CMakeLists.txt separately against the matching OCCT libraries. Managed sources and the resulting DLL are one inseparable artifact set.

Capabilities and configuration

Preparation and output boundary

OcctParseModule → OcctCompilerProbeModule → OCCT provider model
  → Shared root/dependency closure + normalization → one validated GenerationPlan
  → CleanGenerationOutputModule → GenerateCSharpModule + GenerateCppModule

Parsing, compiler probes, OCCT classification, and finite OCCT emission policy are provider-owned. The provider converts Clang declarations into Shared's normalized records, members, types, transport, lifetime, layout, and template facts. Shared then owns dependency closure, semantic admission, managed and native declaration emission, source inventory, slot ordering, and final plan construction. Both emitted languages therefore consume the same normalized model and exact export order. Preparation failures, missing dependencies, rejected semantics, invalid paths, collisions, duplicate exports and cancellation fail the pipeline instead of yielding a successful empty set.

The provider owns OCCT error projection, headers, native dependency choices, compiler options, and unity grouping facts as finite profile or supplemental metadata. Shared owns declaration emission, deterministic CMake construction, publication, loader, and function table. Record/template-family and enum emission limits remain unchanged; this migration does not adopt a benchmark strategy.

Native source filenames use a readable stem capped at 80 characters, with a stable hash for long template names. This leaves room for CMake's object-directory suffix in nested worktrees without changing managed names or native exports. The Windows build rejects unsafe CMake object-path warnings before compilation; use a shorter output root if the checkout still exceeds that budget.

Each supported object has one unmanaged physical representation. Reference returns remain ref readonly T or ref T, subject to native owner lifetime and invalidation rules. Transient operations expose separate direct Handle<T> and in handle<T> receivers invoking the same slot; only the owning overload checks owner liveness. Lowercase handle<T> is non-owning storage, not an owner interface. Handles returned by value use owning Handle<T>; non-transient RAII uses generic Owned<T>.

Overlapping ordinary fields, including union members, use same-named ref T properties over shared sequential storage (ref readonly T for const storage). References alias native bytes without copying, retaining or allocating. Non-overlapping fields remain fields; bitfields remain value properties. Reference accessors also preserve aliasing through in or ref readonly containing receivers, without defensive copies. Reflection and field-specific syntax must account for the property distinction. Callers must obey native union active-member, construction/destruction, owner-lifetime and invalidation rules; accessing a generated property does not activate a union member.

Representable template type arguments stay generic; non-type values and unrepresentable arguments such as void are fixed into the family name. A shared managed family requires a valid physical graph. Each selected closed native specialization retains direct invocation slots without runtime generic native dispatch.

Explicit full specializations retain their own closed declarations. Template families with distinct native base identities also remain closed; fixed-base families can share a managed type while retaining the exact base interface. Generic base dependence is not inferred from coincident type spellings. Family compatibility is finalized only after native ownership classification.

Fail-closed limitations

The installed headers and DLLs are authoritative. Incomplete/inaccessible declarations, unrepresentable layout/transport, unsafe ownership, unavailable copying/destruction and uncallable members are rejected at the narrowest safe boundary. Templates, streams and smart pointers are not excluded merely by category; each concrete specialization needs proof.

All-header discovery excludes missing/broken include dependencies and their dependants, the installed broken MathLin_Jacobi.hxx, and incompatible desktop/GLES declarations from OpenGl_GLESExtensions.hxx. It reports exclusions without patching installed headers. Exact members proved absent from the Windows libraries are recorded in UnsupportedNativeExports.txt. Recreate linker evidence when the native installation changes; do not replace a member failure with broad type exclusion.

The repository has no vcpkg manifest; maintainers supply the documented installation. No Linux, ARM, alternate compiler ABI, replaceable native DLL, or published package is implied.

Verify

From the repository root, run all-header source generation:

$env:VCPKG_ROOT = 'C:\vcpkg'
dotnet run --project src/tools/TedToolkit.CppBindings.Windows.Generation.Tool/TedToolkit.CppBindings.Windows.Generation.Tool.csproj -c Release -- --provider occt --repository-root . --output-root output/generated --vcpkg-root $env:VCPKG_ROOT --configuration Release

dotnet build TedToolkit.CppBindings.slnx -c Release additionally builds the Windows project's matched native artifact using Visual Studio's MSVC and Ninja tools. The separate TedToolkit.CppBindings.Occt.GeneratedSmoke executable exercises native Value, Owned, Handle, inheritance and error behavior. TUnit regressions live in TedToolkit.CppBindings.Occt.Generator.Tests. The independent generic package consumer proves the public provider boundary, not OCCT correctness.

pwsh -NoProfile -File Build/VerifyOcctGeneratorPackage.ps1 packs and consumes this provider in an isolated project, checks header source-generator assets and public identities, and compares two real-header generation runs. After a successful Release solution build, pwsh -NoProfile -File Build/VerifyWindowsPackage.ps1 consumes the matching Windows package and its direct analyzer package through the native smoke test without generating code in the consumer.

Repository overview · Runtime · Platform architecture