> 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. 

Openembedded-core mailing list

Reply via email to