Skip to main content

Native Providers (C++ Interop)

The legacy modulecpp declaration was removed from the language surface (see diagnostics: “The modulecpp declaration was removed.”). Native C++ interop is configured on the project manifest using [native] / [native.<Provider>] (and optional [vcon.native] / [vcon.native.<Provider>] mirrors), as parsed in ProjectConfig.cpp.

Morph surface: depend on the module​

Pull symbols from a natively backed module the same way as any other dependency:

module MyNativeLib;

Init method() {
    result is MyNativeLib.Compute(42);
    Print(result);
}

Use module, not a separate import keyword.

Configure the provider in morph.toml​

Keys accepted for [native.mylib] (provider id mylib) include:

  • manifest — path to the native provider manifest (see NativeProviderManifest / .toml format in-tree).
  • source_dir — root of native sources.
  • build_system — e.g. cmake.
  • cmake_target — target to build.
  • artifact.<platform> — per-platform artifact paths when needed.

Example:

[native.mylib]
manifest = "native/mylib/manifest.toml"
source_dir = "native/mylib"
build_system = "cmake"
cmake_target = "mylib"

Enable native bridging at package level with [native] enabled = true when required; [vcon.native] can mirror enablement for VCON-oriented flows. Exact merging rules follow ProjectConfig.cpp (native and vcon.native stay in sync for provider maps).

How it fits together​

  1. Author C/C++ (or CMake) for the provider and expose exports through the manifest.
  2. Point morph.toml at that manifest and build metadata.
  3. Reference the logical Morph module name with module MyNativeLib; from .mx sources.

Next steps​