OCCT wasm build/API compatibility documentation (exports, bindings, supported workflows)

[0x46y]

Summary

When integrating different OCCT wasm artifacts/builds (legacy repository,
current monorepo artifacts, and custom rebuilds), we encountered repeated
integration difficulties even when the OCCT usage code remained largely the
same.

The main differences encountered were:

• wrapper / initialization format differences
• exported class and function set differences
• binding method signature differences
• capability differences (for example STL import availability)

These differences make it difficult to create reproducible browser-based
integrations and to extend the wasm build with custom functionality.

Why this matters

For browser-worker integrations these differences can lead to:

• runtime initialization failures
  (for example missing factory/module entrypoints)

• API call mismatches
  (unexpected argument count or binding signature differences)

• certain features silently unavailable depending on the build

This increases the amount of trial-and-error required to integrate
OCCT wasm builds in browser environments.

Proposal

It would be very helpful if OCCT wasm artifacts included documentation
describing build/API compatibility expectations.

Examples of useful information:

Wrapper / initialization format

• expected global entrypoint(s)
• recommended worker loading pattern
• compatibility with importScripts or module loading

Exported API profile

• classes/functions expected for common geometry workflows
• optional capability sets (for example minimal vs IO-enabled builds)

Binding signature notes

• notes when binding signatures change between builds
• migration guidance for downstream integrations

Supported workflow matrix

Examples:

• STEP / IGES import
• STL import / export
• BRep read / write
• volume computation via GProp_GProps / BRepGProp_VolumeProperties

Reproducible build reference

For published artifacts, information such as:

• OCCT source commit
• toolchain / container used for building
• build configuration used for exported bindings

Goal

Clear documentation describing wasm build/API compatibility would
reduce integration friction and make browser deployments more
predictable and reproducible.

[0x46y]

Example compatibility checklist that could help downstream integrations

To make the proposal more concrete, here is an example of a minimal
compatibility checklist that could help downstream integrations
understand OCCT wasm build capabilities.

1. Initialization compatibility

• Worker-compatible initialization entrypoint
  (for example global factory / module pattern)

• Documented loading pattern
  (for example importScripts compatibility)

2. IO capability matrix

• STL import support (reader available?)
• STL export support
• STEP / IGES import support

3. Geometry / analysis capability matrix

• GProp_GProps constructor availability
• BRepGProp_VolumeProperties availability / status
• Any known wasm-specific limitations

4. Solidification guidance

• Recommended validation checks after MakeSolid
• Example topology sanity checks
  (for example face count > 0 before trusting volume)

5. Reproducible published build information

• OCCT source commit used
• toolchain or container used for the build
• binding/export profile identifier