forked from lix-project/lix
37fca662b0
In https://github.com/NixOS/nix/pull/6311#discussion_r834863823, I realized since derivation goals' wanted outputs can "grow" due to overlapping dependencies (See `DerivationGoal::addWantedOutputs`, called by `Worker::makeDerivationGoalCommon`), the previous bug fix had an unfortunate side effect of causing more pointless rebuilds. In paticular, we have this situation: 1. Goal made from `DerivedPath::Built { foo, {a} }`. 2. Goal gives on on substituting, starts building. 3. Goal made from `DerivedPath::Built { foo, {b} }`, in fact is just modified original goal. 4. Though the goal had gotten as far as building, so all outputs were going to be produced, `addWantedOutputs` no longer knows that and so the goal is flagged to be restarted. This might sound far-fetched with input-addressed drvs, where we usually basically have all our goals "planned out" before we start doing anything, but with CA derivation goals and especially RFC 92, where *drv resolution* means goals are created after some building is completed, it is more likely to happen. So the first thing to do was restore the clearing of `wantedOutputs` we used to do, and then filter the outputs in `buildPathsWithResults` to only get the ones we care about. But fix also has its own side effect in that the `DerivedPath` in the `BuildResult` in `DerivationGoal` cannot be trusted; it is merely the *first* `DerivedPath` for which this goal was originally created. To remedy this, I made `BuildResult` be like it was before, and instead made `KeyedBuildResult` be a subclass wit the path. Only `buildPathsWithResults` returns `KeyedBuildResult`s, everything else just becomes like it was before, where the "key" is unambiguous from context. I think separating the "primary key" field(s) from the other fields is good practical in general anyways. (I would like to do the same thing for `ValidPathInfo`.) Among other things, it allows constructions like `std::map<Key, ThingWithKey>` where doesn't contain duplicate keys and just precludes the possibility of those duplicate keys being out of sync. We might leverage the above someday to overload `buildPathsWithResults` to take a *set* of return a *map* per the above. ----- Unfortunately, we need to avoid C++20 strictness on designated initializers. (BTW https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2287r1.html this offers some new syntax for this use-case. Hopefully this will be adopted and we can eventually use it.) No having that yet, maybe it would be better to not make `KeyedBuildResult` a subclass to just avoid this. Co-authored-by: Robert Hensing <roberth@users.noreply.github.com> |
||
|---|---|---|
| .github | ||
| config | ||
| contrib | ||
| doc | ||
| m4 | ||
| maintainers | ||
| misc | ||
| mk | ||
| perl | ||
| scripts | ||
| src | ||
| tests | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .gitignore | ||
| .version | ||
| boehmgc-coroutine-sp-fallback.diff | ||
| bootstrap.sh | ||
| configure.ac | ||
| CONTRIBUTING.md | ||
| COPYING | ||
| default.nix | ||
| docker.nix | ||
| flake.lock | ||
| flake.nix | ||
| local.mk | ||
| Makefile | ||
| Makefile.config.in | ||
| precompiled-headers.h | ||
| README.md | ||
| shell.nix | ||
Nix
Nix is a powerful package manager for Linux and other Unix systems that makes package management reliable and reproducible. Please refer to the Nix manual for more details.
Installation
On Linux and macOS the easiest way to install Nix is to run the following shell command (as a user other than root):
$ curl -L https://nixos.org/nix/install | sh
Information on additional installation methods is available on the Nix download page.
Building And Developing
See our Hacking guide in our manual for instruction on how to to set up a development environment and build Nix from source.
Additional Resources
- Nix manual
- Nix jobsets on hydra.nixos.org
- NixOS Discourse
- Matrix - #nix:nixos.org
- IRC - #nixos on libera.chat
License
Nix is released under the LGPL v2.1.