Side note: this is why we're still using copyleft_compliance at Mentor Graphics, rather than moving to archiver, even though it results in re-execution of do_fetch on recipes that were built from sstate.

(In reply to comment #0)
> As archiver is implemented via hooks on regular tasks, none of its work runs
> when using sstate, and also no tasks are provided to produce sstate archives
> for what it produces. As a result, the only way to get useful output from
> archiver.bbclass today seems to be only doing a full 100% from scratch build.
> 
> I think we need to find a good approach to address this, particularly as now
> it's quite often to do builds partially from sstate and partially from

s/often/common/

> scratch, which would lead to half-populated archiver content.

Putting the output from the archiver tasks under sstate control would seem to be the answer, as we do for do_populate_lic. It shouldn't be hard to do and just involves staging the output to an intermediate directory.

To summarize the behaviors and some of my considerations/concerns about a potential fix:

copyleft_compliance adds a task after fetch which deploys those bits into deploy, and arranges for this task to be run against all recipes. As it's not hooked into shared state, and is an independent piece of the task graph (not covered by any of the sstates), its tasks are run even when building from shared state.

archiver implements a variety of hooks, designed to run at various points in the build process, to capture various build artifacts. Not just the fetched sources the way copyleft_compliance does, but also logs of the built tasks, etc. These hooks are then used by inheriting one of the archive-*-source classes, which adds them to prefuncs/postfuncs of tasks. prefuncs/postfuncs are not automatically added to the checksums for those tasks, and the output created by the hooks is not captured by any of the shared state code, so this output is only ever produced when building the recipe from scratch. When building a recipe from shared state, no archival would occur at all. Obviously this is a problem.

There are a few possible approaches to dealing with this.

Richard has suggested integrating it into shared state: make the hooks store their output in some safe location (e.g. in the sysroots), and then have a task which archives up the content placed in that location, and implement shared state for that task (to see an example of how a task is set up for use with shared state, see deploy.bbclass, which does so for the do_deploy task).

This is a nice easy way to at least get consistent behavior back, but the problem with this approach is that we end up tarring up a bunch of content from DL_DIR, duplicating it locally, unnecessarily unarchiving that content when building from shared state (debatable), and worst, it means when fetching from SSTATE_MIRRORS, we'd be basically redownloading all the sources to everything we build. First, from DL_DIR, second, from SSTATE_MIRRORS. This would be a definite problem in Mentor's product, where we'll likely stop shipping shared state and instead provide an sstate mirror. So the customer would have the downloads already, yet have to redownload them in another form (sstate archive) if they want to leverage archiver, or would end up needing to rerun tasks. This may well be the only viable option, but I'd like to give further thought to the options.

Another possibility would be to take the output captured in the hooks and actually get it included into the various shared states. For example, configured sources could be placed in the do_populate_sysroot sstate directory and captured by do_populate_sysroot's sstate archive. Then our added task could pull the bits from the sysroot regardless, and those bits would always be there, whether added by sstate or from scratch -- but of course, the problem with that is, the sstate archive contents would change without the checksum changing, meaning that it'd be possible to use one mirror that has sstates without this content, and another mirror that has sstates with this content, and there'd be no way to know which would be used when.

A variant of that would be to include the prefuncs/postfuncs in the task checksums, meaning that the use of archiver would affect signatures, and disabling/enabling archiver would change them, meaning that one build with and one build without would not fully leverage shared state between them. This may be best, or some variant of this. It would also be possible, depending on the impact, to just make certain bits always available. For example, archiving configured sources always wouldn't be a good idea, but it'd cause trivial impact to always make logs and scripts available in the sysroot, even if archiver isn't running, which would mean that hook wouldn't be needed, and it'd be slightly less impact on the checksums.

This was fixed by others a while back, resolving to clean up.