Summary
Build apLib as a static lib and engLib as a dynamic lib (engLib.dll + import lib), with apLib.lib linked into engLib.dll. engine.exe, engtest.exe, and future C++ node DLLs link only engLib.dll — never apLib.lib directly. Result: one shared engine module that node DLLs import, with a single instance of all process-global state and, because there is only one dynamic module, one copy of every third-party dependency.
Why this layout
Avoids the vcpkg overlap of two DLLs: with a single dynamic module, deps used by both cores (e.g. OpenSSL — direct in apLib, transitive via aws/azure/cpprest in engLib) are linked once into engLib.dll instead of duplicated. No per-port dynamic triplet overrides, and no CMake-target merge — apLib.lib builds separately and is absorbed. aptest keeps linking apLib.lib standalone, so it stays lean.
Scope
engLib → SHARED; apLib stays STATIC, linked privately into engLib.dll (absorbed). Ensure engine/engtest/node DLLs link engLib.dll only and never static-link apLib.lib — otherwise apLib, its deps, and the Factory registry duplicate per consumer. Update the prebuilt-lib path accordingly.- Single-instance globals: de-inline the header-defined Meyers singletons — starting with
Factory::factories() (apLib/factory/Factory.h) — into a .cpp compiled once and exported; audit logger/allocator/other mutable header statics likewise.
- Explicit cross-platform export policy (public API only): the exported surface spans both apLib and engLib (apLib lives inside
engLib.dll), so apLib compiles in "export" mode. Hidden-by-default visibility + one dllexport/dllimport ↔ visibility("default") macro, modeled on CLASSIFY_API (include/classify_api.h). Don't rely on platform defaults (WINDOWS_EXPORT_ALL_SYMBOLS skips data symbols).
- Reconcile PCH reuse (
engine REUSE_FROM engLib) with the export/import switch.
Acceptance
engine.exe, engtest.exe, and aptest build, link, and pass the existing test suite against engLib.dll (apLib absorbed). Final proof that a second in-process module shares the one registry lands with the node POC in #1577.
Out of scope
The node loader, initializeNode contract, and the C++ node itself — those remain in #1577.
Parent
Part of #1577 (C++ node).
Summary
Build
apLibas a static lib andengLibas a dynamic lib (engLib.dll+ import lib), withapLib.liblinked intoengLib.dll.engine.exe,engtest.exe, and future C++ node DLLs link onlyengLib.dll— neverapLib.libdirectly. Result: one shared engine module that node DLLs import, with a single instance of all process-global state and, because there is only one dynamic module, one copy of every third-party dependency.Why this layout
Avoids the vcpkg overlap of two DLLs: with a single dynamic module, deps used by both cores (e.g. OpenSSL — direct in apLib, transitive via aws/azure/cpprest in engLib) are linked once into
engLib.dllinstead of duplicated. No per-portdynamictriplet overrides, and no CMake-target merge —apLib.libbuilds separately and is absorbed.aptestkeeps linkingapLib.libstandalone, so it stays lean.Scope
engLib→SHARED;apLibstaysSTATIC, linked privately intoengLib.dll(absorbed). Ensureengine/engtest/node DLLs linkengLib.dllonly and never static-linkapLib.lib— otherwise apLib, its deps, and theFactoryregistry duplicate per consumer. Update the prebuilt-lib path accordingly.Factory::factories()(apLib/factory/Factory.h) — into a.cppcompiled once and exported; audit logger/allocator/other mutable header statics likewise.engLib.dll), so apLib compiles in "export" mode. Hidden-by-default visibility + onedllexport/dllimport ↔ visibility("default")macro, modeled onCLASSIFY_API(include/classify_api.h). Don't rely on platform defaults (WINDOWS_EXPORT_ALL_SYMBOLSskips data symbols).engine REUSE_FROM engLib) with the export/import switch.Acceptance
engine.exe,engtest.exe, andaptestbuild, link, and pass the existing test suite againstengLib.dll(apLib absorbed). Final proof that a second in-process module shares the one registry lands with the node POC in #1577.Out of scope
The node loader,
initializeNodecontract, and the C++ node itself — those remain in #1577.Parent
Part of #1577 (C++ node).