This is a compile workload.

There are a number of problems associated with compile workloads. One
is that full provenance tracking requires taking cognizance of the
compiler's standard include files and libraries. I expect that
handling these as their own objects in a workflow engine is
problematic; also, because they aren't the same from compiler to
compiler, the workload results wouldn't be comparable from project to
project.

Another problem is that compile workloads are generally already driven
by a workflow engine, that is, make. Translating makefiles (especially
nontrivial makefiles) into workflow specifications for the workflow
engines most of the IPAW community uses is likely to to be at least
somewhat problematic, especially because in the more interesting
compiles part or all of the makefile material is generated on the fly.
Properly, the generated makefiles should be artefacts in the
provenance system and make should consume them - but then the whole
compile becomes a single make invocation and all detail is lost.

The third problem is scale: compile workloads tend to be very large by
the standards of the original challenge. The sample kernel compile in
our traces library has about 17,000 distinguishable entities. Entering
these all by hand into a workflow engine is a non-starter.

I've arranged a workload that mostly addresses these problems at the
cost of being somewhat unnatural. To deal with the standard includes
issue, I've chosen a kernel compile as the basis for the workload;
kernels are self-contained so kernel compiles do not depend on the
compiler's headers and libraries. To deal with make, I've specified
the workload so that the workflow engine runs make repeatedly to
generate one result at a time. And to deal with scale, I've started
with a toy kernel and then cut most of it out to reduce it to a size
that I hope will be manageable for all the workflow engines.