> > 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. > > That would be very much appreciated!
Here's a prototype bbclass: https://gist.github.com/mostthingsweb/39e24b329de70c0212e5bf21a431e143. Please give it a try. All you need to do is INHERIT it in local.conf: INHERIT += "revrecord" Then you can just do "bitbake --parse-only" and during parsing it will create a directory structure in ${TOPDIR}/revs that looks something like this: revs ├── 20200116170750 │ ├── recipe1 │ │ └── revs.inc │ ├── recipe2 │ │ └── revs.inc │ ├── recipe3 │ │ └── revs.inc │ └── revs.inc └── latest -> 20200116170750 It also supports multiconfig. When multiconfig is enabled, there will be an additional layer of directories in the 'revs' directory, one per multiconfig (plus "default"): revs ├── 20200116170750 │ ├── default │ │ ├── recipe1 │ │ │ └── revs.inc │ │ ├── recipe2 │ │ │ └── revs.inc │ │ └── revs.inc │ └── mc1 │ ├── recipe1 │ │ └── revs.inc │ ├── recipe2 │ │ └── revs.inc │ └── revs.inc └── latest -> 20200116170750 TODO: * Right now, the class triggers a base environment change every time, which means BitBake always reparses every recipe. I guess this is because I'm modifying the datastore when I get bb.event.ConfigParsed and bb.event.MultiConfigParsed, in order to ensure REVRECORD_DATETIME is the same across all configurations when multiconfig is active. Perhaps there is a more elegant way to do this that won't trigger the environment change? To be fair I think in most cases you won't care, since I expect this class to mainly be used in a continuous integration environment where you'll be doing a clean build and having to reparse everything anyway. But I could also see this class a useful to thing to always have enabled, even for personal builds, and in that case obviously I'd want to fix this issue. * When multiconfig is active, I would also like a "global" revs.inc to be generated, which is the product of aggregated the "revs.inc" for all the multiconfigs. Still need to think about how exactly this will work in the face of conflicting SRCREVs. * We have a use case for JSON format data as well ("revs.json") - I'll add that too. * Possibly a small tinfoil script that simply automates the task of INHERIT'ing this class, parsing all the recipes, and then dumping revs.inc. Thanks, Chris -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
