A modern, delicious implementation of the Nix package manager, focused on correctness, usability, and growth — and committed to doing right by its community https://lix.systems
Find a file
John Ericson 37fca662b0 Make KeyedBuildResult, BuildResult like before, and fix bug another way
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>
2023-04-15 11:01:31 -04:00
.github Merge pull request #8153 from obsidiansystems/more-labeler 2023-04-11 12:10:34 +02:00
config Run autoupdate 2021-06-01 11:42:38 +02:00
contrib function-trace: always show the trace 2019-09-18 23:23:21 +02:00
doc Merge pull request #7864 from obsidiansystems/quickstart-long-options 2023-04-14 09:13:16 -04:00
m4 autoconf: Fix C++17 detection not working on Ubuntu 16.04. 2019-07-03 04:32:25 +02:00
maintainers Merge pull request #7579 from fricklerhandwerk/review-process 2023-04-05 01:57:17 +02:00
misc Add a setting for configuring the SSL certificates file 2023-03-17 18:32:18 +01:00
mk Enable -Werror=switch-enum 2023-04-03 18:45:20 +02:00
perl Fix building with GCC 9 2023-02-10 18:38:57 +01:00
scripts Merge pull request #7925 from cole-h/fixup-xdg-nix-env 2023-03-01 23:01:42 +01:00
src Make KeyedBuildResult, BuildResult like before, and fix bug another way 2023-04-15 11:01:31 -04:00
tests Do not gate or hide experimental settings 2023-04-11 10:56:48 -04:00
.dir-locals.el .dir-locals.el: Set c-block-comment-prefix 2020-07-10 11:21:06 +02:00
.editorconfig Add .editorconfig 2017-06-05 22:57:28 +01:00
.gitignore Single page for experimental feature descriptions 2023-04-09 11:01:23 -04:00
.version Bump version 2023-04-11 20:16:37 +02:00
boehmgc-coroutine-sp-fallback.diff Always disable GC in a coroutine unless the patch is applied 2023-04-07 14:54:38 +02:00
bootstrap.sh bootstrap: Simplify & make more robust. 2011-09-06 12:11:05 +00:00
configure.ac add check for librapidcheck 2023-04-08 22:29:43 +02:00
CONTRIBUTING.md Add CONTRIBUTING.md 2023-03-11 22:14:14 +01:00
COPYING * Change this to LGPL to keep the government happy. 2006-04-25 16:41:06 +00:00
default.nix add flake-compat to flake.nix and use sha256 in default.nix 2023-03-06 21:11:24 +01:00
docker.nix docker.nix: add an option to include flake-registry inside docker image (#6750) 2023-03-22 20:55:02 +01:00
flake.lock add flake-compat to flake.nix and use sha256 in default.nix 2023-03-06 21:11:24 +01:00
flake.nix fix failing configure in nix-tests 2023-04-09 02:33:53 +02:00
local.mk Enable -Werror=switch-enum 2023-04-03 18:45:20 +02:00
Makefile Generate API docs with Doxygen 2023-03-10 12:51:06 -05:00
Makefile.config.in Generate API docs with Doxygen 2023-03-10 12:51:06 -05:00
precompiled-headers.h Config: Use nlohmann/json 2020-08-20 11:02:16 +02:00
README.md Improve hacking.md 2023-02-13 12:00:00 +04:00
shell.nix Remove url literals 2022-01-24 13:28:21 +01:00

Nix

Open Collective supporters Test

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

License

Nix is released under the LGPL v2.1.