Hi Richard, > I tried some experiments and this doesn't actually turn out to be so difficult > to do. I've included a patch below which basically drops the SRCPV pieces > into PKGV, the conditional can probably be simplified further. > > This patch isn't quite right in that we need to split get_srcrev into two > versions, one which returns the SRCREV_FORMAT string and one which > returns the full hashes for taskhash purposes. > > The nice thing about this approach is that SRCPV can simply be removed over > time, it no longer does anything. That means compatibility is retained with > existing recipes. > > I've not tested this extensively yet with AUTOREV but normal builds appear > to work ok with it and the WORKDIR directory naming simplification is > probably a win.
This sounds interesting; thank you for your tiresome work! I will try to find some time to play with the patch. Just to add another dimension to the discussion, I wonder how (if at all) this could affect how cve-check.bbclass works? One thing I don't like about that class is that the CVE checking happens after do_fetch, when really all do_cve_check cares about is the resolved revision. Is there an opportunity here to optimize do_cve_check? Over the past few months (maybe even longer), I've had an idea in my head for a task that happens before do_fetch that actually performs revision resolution. Maybe do_resolve_autorev or something. But I think your recent work obsoletes that idea. Thanks, Chris
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1733): https://lists.openembedded.org/g/openembedded-architecture/message/1733 Mute This Topic: https://lists.openembedded.org/mt/100618420/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
