The plan tracks compiles and runs in separate tables, with separate statuses. This is wasteful because:
it wastes space in the plan file (and plan files are quite big!);
the analyser has to piece together information about each compilation from two separate tables;
compile and run statuses are entirely disjoint, with the exception of Ok, and so they could be tracked in one place rather than two;
minor point but, when we fix #59, the fix would need to drop two tables instead of one.
It also doesn't make much sense from a division-of-labour perspective: both compile and run are governed by the invoker, and there is always a 1 to 1 relationship between the two.
As such, I'm suggesting that the two tables merge into one invocations (or maybe compilations) table, which would look like this:
{
// ...
"invocations": {
"gcc.4": {
"status": "Ok",
"compile": {
// compilation stuff goes here
},
"run": {
// run stuff goes here
}
}
}
// ...
}
As for the overlap between Ok meaning 'compile ok' and 'run ok', I'd either make a new NeedsCompile status, omit status when it's indeterminate, or have the presence or absence of run disambiguate. Hmm.
The plan tracks compiles and runs in separate tables, with separate statuses. This is wasteful because:
Ok, and so they could be tracked in one place rather than two;It also doesn't make much sense from a division-of-labour perspective: both compile and run are governed by the invoker, and there is always a 1 to 1 relationship between the two.
As such, I'm suggesting that the two tables merge into one
invocations(or maybecompilations) table, which would look like this:As for the overlap between
Okmeaning 'compile ok' and 'run ok', I'd either make a newNeedsCompilestatus, omit status when it's indeterminate, or have the presence or absence ofrundisambiguate. Hmm.