This way, the crates can be published without interfering with
potential future non-bindings `nix-` crates, if Nix proper wants to
have native rust code, for instance.
The rename makes it so that we'll have the original name for the more
sensible lazy behavior.
(cherry picked from commit 6fdae53df54da0c6349ac32789ec67e3a25a5774)
This builds on the previous commit to make it compatible with the
currently locked build configuration.
(cherry picked from commit bd1edec2fa5251263c768c3e2b312eb4f21d2bb4)
Fixes#106
The Nix settings system uses global mutable state without internal
synchronization. When multiple threads call settings::set concurrently
(as happens in parallel test execution), this causes a segfault in the
C++ std::set implementation.
Changes:
- Add mutex to serialize access through the Rust API
- Add documentation explaining thread safety limitations
- Add Once guard in nix-flake tests to minimize concurrent access
The mutex provides protection between Rust callers, though it cannot
completely prevent C++ Nix code from modifying settings concurrently.
(cherry picked from commit 203917657b60c4e1dcbaf442bec64c37c634abc4)
Exposes the Value constructors, for use by other bindings like
nix-flake, which needs to construct e.g. a flake outputs Value.
See https://github.com/nixops4/nixops4/issues/25
> We have two related issues:
> A bunch of implementation details cannot be made private, since they must be used from one of the other crates (e.g. Values are defined in the value module but used from eval_state
> While we don't want users to need to use these features, it may be good to provide escape hatches so they can interface with the raw API if they need more control.
> Problem (1) has been solved in other crates with a __private module with #[doc(hidden)] set. See for instance:
I'm leaving docs turned on for (2). The issue has more thoughts about
alternatives.
(cherry picked from commit eb6744d1519febe5b6aa6233eb3f3e8a049f12d4)
This supports the more "advanced" `nix_eval_state_builder`, which
has more methods that we'll want to use.
(cherry picked from commit a96047000df6b7022d166a8c35bb6e3075e5eddb)
Note that `"auto"` holds a strange middle ground, reading
part of the general environment, but not all of it. It
ignores `NIX_REMOTE` and the `store` option.
(cherry picked from commit 7ba92a3793c2fe11938e802e6b61edee042b193a)
In the previous update commit, the Nix `cc.version` didn't match the
in-output directory name anymore, causing a build failure.
By asking GCC properly, we are robust against such discrepancies.
The script isn't great, relying on GCC "log" output specifics, but it
seems that the GCC output has been like this for a while, and the
lines before and after seem to be intentional about their purpose...
(cherry picked from commit 68f928555660cb914105b0ad668d6cadc25223e9)
... because it is. I had previously dismissed the comparatively
trivial unsafety of these functions, assuming the caller is
aware of the purpose of them and reasonably familiar with manual
memory management.
That would have been fine in an unsafe by default language like C++,
which Rust is not.
(cherry picked from commit b43455fdd0468f067741a79a7031ba2fa907f0eb)
Fixes https://github.com/nixops4/nixops4/issues/65,
possible undefined behavior.
This doesn't make the code nice wrt *const/*mut distinction, but
since we're not mutating it, this should be fine.
(cherry picked from commit 75d448aad923a5f835f0562400e223df43103ea4)
Fixes tests hanging. Before this commit:
nix build .#packages.x86_64-linux.nixops4-eval-release
See https://github.com/NixOS/nix/issues/11979
(cherry picked from commit 03af71f92488f2ee683565318f24afd3e3c001df)
Closes#31
A guard object is more capable, as it can be used in various
control flow and ownership schemes, including async code, but not
that it is not Send.
(cherry picked from commit f9aa5eab2561834c64ef9fe01979a91aee35848f)
