> From: LAPLANTE,CHRIS (Agilent USA)
> Sent: Thursday, January 16, 2020 3:21 PM
> To: Pascal Huerst <pascal.hue...@gmail.com>; Richard Purdie
> <richard.pur...@linuxfoundation.org>; openembedded-
> c...@lists.openembedded.org
> Cc: Rich Persaud <pers...@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
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
