> 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.
Chris
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
