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

[chris.laplante at agilent.com]

> From: LAPLANTE,CHRIS (Agilent USA)
> Sent: Thursday, January 16, 2020 3:21 PM
> To: Pascal Huerst <pascal.huerst at gmail.com>; Richard Purdie <richard.purdie at linuxfoundation.org>; openembedded-
> core at lists.openembedded.org
> Cc: Rich Persaud <persaur at gmail.com>
> Subject: RE: [OE-core] Looking for a way to build latest tagged releases in recipes
> 
> > 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.
> 

I did some thinking about the second TODO item I had and I've decide that it is unnecessary. One revs.inc for each multiconfig is fine. To use them to reproduce a build, you simply dump the contents of each revs.inc into the corresponding multiconfig conf (or local.conf for "default"). Any algorithm I try to come up with to combine them all into a single file (for local.conf) is bound to be wrong in some way.

The third TODO is also done. The only TODO remaining is #4, a tinfoil wrapper, but so far I don't see a need. 

Chris