On Fri, 5 Nov 2021 at 16:24, Jasper Orschulko <
Jasper.Orschulko@iris-sensing.com> wrote:

>
> In our case some binary which is made up from some 50ish separately
> versioned sub-components. We used to have separate recipes for each of
> this components and static link them using DEPENDS. However, this does
> not scale well. E.g. if you want to create another version with
> different cmake flags, you would have to create copies of all 50ish
> recipes. You could move all the components into a single recipe and do
> 50x git fetcher, but keeping this versioned is still painful.
> Especially since the developers mainly don't use yocto but use the SDK
> for cross-compiling. As such this used to mean, that versioning in the
> development workflow and the release workflow worked differently ->
> more maintenance work.
>
> With repo fetcher we can streamline the versioning within the yocto
> build process and the daily developer workflow, as both can fetch the
> repo manifest from a central stored git repo. The idea is, that the
> repo manifest defaults to develop branch for all component repos and if
> we want to create a release we can use repos own tooling to
> automatically create fixed refspecs from the development manifest.
> something like `repo manifest -r -o release-1.0.0.xml`, push that as a
> release to the manifest repo, set this release as refspec in the recipe
> within the meta layer and proceed with the release process. So no more
> manually maintaining the component versioning within the yocto recipes.
>

I see. I don't particularly endorse that you invented a custom, proprietary
workflow that you have to support entirely by yourselves - instead of
finding ways to do what you need with standard yocto tooling, improving the
tooling where/if necessary. But if that works out ok for you, then fine :)

Alex