There's currently no good way to embed an `sdkcraft` definition in existing projects. A common SDK tree will look like: ``` . ├── hooks │ └── setup-base ├── README.md ├── sdkcraft.yaml └── tests ├── main │ └── launch │ ├── consumer.cpp │ ├── task.yaml │ └── workshop.yaml.in └── spread.yaml 5 directories, 7 files ``` At least `hooks` and `sdkcraft.yaml` need to be relocatable so this can coexist within the upstream source repo and reference `source: .`. The `.workshop/<sdk>` could possibly be used here, with `sdkcraft` taking either the SDK name, or the full path, as argument. Alternatively, following other *crafts, `sdk/sdkcraft.yaml`, `.sdk/sdkcraft.yaml`.
Activity
jonathan-conder commentedon Oct 5, 2026
It looks like upstream has support for something like this already, but experimental: https://github.com/canonical/craft-application/blob/02ca7554e0539d91eb48050e0b54619fd10db090/craft_application/services/provider.py#L272
saviq-work commentedon Oct 5, 2026
Snapcraft supports
snap/at least…jonathan-conder commentedon Oct 6, 2026
Yeah I'm not saying we can't do
sdk/or.sdk/, maybe we can also do this.gitdetection thing though