SDK parts

Parts provide a way to modularize the SDK and manage its dependencies, ultimately making it easier to maintain and update by separating its deployment into sourcing, building and staging phases.

Summary

Parts can be thought of as the building blocks of an SDK. Each part in the definition encapsulates a different aspect of the SDK and focuses on a specific feature or resource; these can be libraries, binaries, or configuration files.

A part defines a number of preset attributes and lifecycle stages in YAML; SDKcraft executes these definitions stage by stage and iteratively resolves any dependencies between parts. Eventually, this results in a uniform SDK, ready for publishing and installation; such SDKs arrive to the users prebuilt, allowing to factor out build activities from SDK hooks that Workshop executes inside the workshop at runtime.

Implementation notes

Full disclosure: SDKcraft borrows the Craft Parts mechanism from the upstream Craft Application project, ultimately sharing it with such tools as Snapcraft and Charmcraft, so general approaches that work for any of those will apply here.

Aside from not yet allowing stage-packages and stage-snaps, SDKcraft doesn’t further limit or expand the parts functionality. However, be aware of the requirements and limitations that the upstream project places on what’s available for a given base, plugin, source and so on.

A detailed explanation is available in the corresponding Craft Parts documentation section.

See also

Explanation:

• SDKs

Reference:

• SDK parts