> 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