24866b71c4
In many cases we are dealing with a collection of realisations, they are all outputs of the same derivation. In that case, we don't need "derivation hashes modulos" to be part of our map key, because the output names alone will be unique. Those hashes are still part of the realisation proper, so we aren't loosing any information, we're just "normalizing our schema" by narrowing the "primary key". Besides making our data model a bit "tighter" this allows us to avoid a double `for` loop in `DerivationGoal::waiteeDone`. The inner `for` loop was previously just to select the output we cared about without knowing its hash. Now we can just select the output by name directly. Note that neither protocol is changed as part of this: we are still transferring `DrvOutputs` over the wire for `BuildResult`s. I would only consider revising this once #6223 is merged, and we can mention protocol versions inside factored-out serialization logic. Until then it is better not change anything because it would come a the cost of code reuse. |
||
---|---|---|
.. | ||
command-installable-value.cc | ||
command-installable-value.hh | ||
command.cc | ||
command.hh | ||
common-eval-args.cc | ||
common-eval-args.hh | ||
editor-for.cc | ||
editor-for.hh | ||
installable-attr-path.cc | ||
installable-attr-path.hh | ||
installable-derived-path.cc | ||
installable-derived-path.hh | ||
installable-flake.cc | ||
installable-flake.hh | ||
installable-value.cc | ||
installable-value.hh | ||
installables.cc | ||
installables.hh | ||
legacy.cc | ||
legacy.hh | ||
local.mk | ||
markdown.cc | ||
markdown.hh | ||
nix-cmd.pc.in | ||
repl.cc | ||
repl.hh |