Skip to main content

Native Providers And Host Interop

Morph package work often meets native interop through providers.

This is where package composition and host-facing boundaries become concrete.

Existing Learn Morph context​

Morph already teaches native provider configuration under Modules. The framework view is the package-author side of the same story:

  • providers are explicit capabilities
  • packages import them through the manifest graph
  • host and artifact relationships are declared, not guessed

User-side native provider config​

Project morph.toml uses [native.<Name>] for provider metadata. Parsed keys (see ProjectConfig.cpp) include manifest, source_dir, build_system, cmake_target, and artifact.<platform>.

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

Optional [vcon.native] / [vcon.native.<Name>] sections align VCON packaging with the same provider map when you use the container stack.

Older docs sometimes showed [vcon.native.modules.*] or manifest_path — those do not match the current ProjectConfig parser; use the keys above.

Morph package authors should keep thinking in terms of:

  • declared provider relationships
  • declared export signatures (native manifest)
  • declared artifact and runtime requirements

not hidden host assumptions.

Why this matters to Morph authors​

The framework carries native provider concepts in:

  • project configuration (ProjectConfig)
  • native provider manifests (NativeProviderManifestParser)
  • semantic / codegen resolution of provider exports and backend hosts

If a package needs host interop:

  1. declare provider relationships explicitly in manifests
  2. keep package-owned behavior in package space
  3. let generic build, execution, and backend hosts do framework-level work

Do not hardwire one package’s host interop policy into core code as a shortcut.

Host interop and LLVM routes​

LLVM routes sit near host interop concerns:

  • provider IDs identify who supplies the capability
  • artifact kinds describe what is produced
  • required extensions describe backend host expectations
  • runtime families describe runtime dependencies

Next steps​