Integrating a native library

For a C/C++ library, first choose an integration boundary. A C# package, C ABI calls through P/Invoke and an engine module are different approaches. A module requires separate engine and template builds for each target platform; dropping a DLL into a project does not register it.

C++ module

1. Create a separate module with its own config.py and SCsub; avoid machine-specific paths in shared build files.
2. Add header locations through CPPPATH. Build dependency sources in a separate environment so their defines/settings do not leak into the engine. The Ogg module demonstrates this structure.
3. For prebuilt libraries, configure platform-specific LIBPATH and LIBS; match architecture, ABI, compiler and Debug/Release runtime. Header paths do not link a library.
4. Register only the engine interface needed. Define ownership and matching deallocation for every buffer; do not free memory through a different allocator.
5. Build separate editor/template variants. Test on a clean target without development-machine paths or DLLs.

Diagnose failures

header not found concerns include paths. unresolved symbol concerns linking or mismatched declarations. DLL/SO loading failure concerns the library, its transitive dependencies or architecture. Crashes during deallocation often require checking ownership boundaries.

Account for dependency licensing and distribution. This page describes the build contract, not a completed third-party integration; no integration build or deployment was executed.