[OE-core] Looking for a way to build latest tagged releases in recipes

chris.laplante at agilent.com chris.laplante at agilent.com
Wed Jan 15 20:59:03 UTC 2020

> I've gone back and forth and re-implemented the code to do so a half dozen times. Chronologically, these are the fundamental
> strategies I've attempted:
> 1. Simply in terms of buildhistory-collect-srcrevs.
> 	Pros: dead simple
> 	Cons: requires that you actually build stuff first; requires buildhistory to be enabled
> 2. As a bbclass, injecting a task between do_fetch and do_unpack ("do_capture_srcrevs")
> 	Pros: can be invoked without actually building stuff, e.g. bitbake my-image --runall=do_capture_srcrevs
> 	Cons: adds yet another task to the recipe; a little ugly since you either need to INHERIT the class, or individually inherit it in
> recipes
> 3. As a separate tinfoil script (as you suggest) which I run before the actual bitbake.
> 	Pros: decoupled from the actual build
> 	Cons: since it's decoupled, it's slower - each recipe needs to be parsed
> 4. Hacking the srcrev cache (inside fetch2) to log all information necessary to generate the SRCREV overrides, paired with a script that
> reads the cache and does it
> 	Pros: Equally suitable for the "config-then-build" workflow ("bitbake --parse-only && generate_overrides.py >> local.conf &&
> bitbake image") or the "build-then-config" workflow ("bitbake image && generate_overrides.py > overrides.conf")
> 	Cons: Invasive, required large changes to fetch2/__init__.py and some smaller changes to fetch2/git.py
> In the current incarnation (#4), I also go a step further and, in cases where a SRC_URI has a parameterized branch, I generate BRANCH
> override lines as well. For example, if I see:

As mentioned in IRC, as I get deeper into it, I'll be going with approach #3 after all :/. Hope to post a tinfoil script soon. 


More information about the Openembedded-core mailing list