Framework Headers And SDK
Morph packages are not just manifest files.
They also consume framework and SDK headers that define the extension surface.
What The SDK Is For
The Morph SDK gives package authors typed ways to describe and implement package behavior.
Examples include:
- feature interfaces
- lowering hooks
- backend host extensions
- execution descriptors
- build pipeline descriptors
The SDK exists so packages can own behavior without editing core internals directly.
Important Header Areas
Some key public extension surfaces live under include/morphc/morph/:
| Header Area | Purpose |
|---|---|
Feature.h | feature-facing SDK concepts |
Lowering.h | lowering-facing extension surface |
MorphABI.h | public Morph ABI contracts |
Execution.h | execution artifact and engine descriptors |
Build.h | build pipeline descriptors |
Tooling.h | tooling command descriptors |
BackendHostExtensions.h | backend host capability hooks |
When To Use The SDK
Use SDK headers when:
- the manifest points to a package-owned implementation class or factory
- a feature needs typed callbacks
- a provider or route needs framework-defined descriptors
- build or execution features must register through public APIs
Do not bypass these surfaces by reaching into random internal source files.
When SDK Work Is Needed
Sometimes the existing SDK is too narrow.
That is the correct moment to widen the framework:
- add a new generic descriptor
- add a new callback interface
- add a new host extension point
Then consume that new SDK feature from the package.
Wrong Direction
Do not add one-off feature behavior to core internals when the real issue is that the SDK needs a generic new capability.
If a package author cannot express a behavior through the SDK, fix the SDK. Do not make core the owner of the feature.
Next Steps
- Scripting And Code Layout - how implementation files are organized around the SDK
- Semantic And Lowering Walkthrough - concrete package lowering code
- Generated Glue And Factories - how manifests and SDK factories meet