Turns out markers are non-deterministic after all and even our patching still
doesn't solve this problem completely. For example (tensorflow deps, this is a
complete diff so actual dependencies don't differ):
30509c30509
< bc527ff00916b15caee38793bca8f294c748df4a256de55c5199281be0489e73 result/@bazel_skylib.marker
---
> 4e0303e815c78df1e43d4b88dfe65e73046e0c6157fb10aa9a4e8b910113cd9c result/@bazel_skylib.marker
31045c31045
< fa13d04b2316214c3b4008b52546c2d5b633e006f6f019d597bb3f9745bacf7b result/@bazel_toolchains.marker
---
> b36174bf5535e5157801b6de30c35ee03a03fe57766306393c3d65dd65cbebf4 result/@bazel_toolchains.marker
31144c31144
< b0ce4a3ac29ac22528336dd3a54b5b7af9ecc43bef2a2630713c1981a5cbbb51 result/@build_bazel_rules_swift.marker
---
> 7492528068ec4f8e7ace2ecf8f933ec4e1b2235bd7426ce6f70177919f1cd05e result/@build_bazel_rules_swift.marker
36245c36245
< be2993536a8233d63251b664caf35b1e7cd57d194ab2a39a293876c232d6bbd0 result/@io_bazel_rules_closure.marker
---
> b6655cc3f2c78525e5a724d8a4e93b1e7f09f1e09fc817d231109e7f39103e88 result/@io_bazel_rules_closure.marker
36329c36329
< 087bc674c9509dfe157400d111db4a13eeb45fc76aeccd490cee9aad6771ecad result/@io_bazel_rules_docker.marker
---
> f920ec07315ec71e800b05cd22b2a341c0a80807c6e335ee81739b13c532b422 result/@io_bazel_rules_docker.marker
79544d79543
< 85893a05a817036c61f6cd9f8247757baa1654f473c494ce4fc5253c2bbd2790 result/@platforms.marker
And here's an example of differences:
$ cat result-a/@bazel_skylib.marker
7dc7472d37424ba5ec6a5532765bc911
$MANAGED
cat result-b/@bazel_skylib.marker
a8f3f577798201157128e8e9934c4705
$MANAGED
Instead of trying to patch these markers further we now completely clear them.
Nix hacks for ignoring markers are restored and expanded so that we don't even
attempt to parse the marker.
* buildBazelPackage: autodetect nix toolchain instead of Xcode on Darwin
* do not export the variables outside of Darwin
* remove unecessary parens
* move comment within the darwin check
Timestamp verification skip is no longer needed (not sure why). Generally we
better off always using the environment hack for all packages because that
ensures all NIX_* flags are correctly applied.
One possible improvement in future is to filter only NIX_* variables to
passthru in Bazel.
Before one would get the following error
nix-repl> pkgs.writeTextDir "share/my-file" "foo"
error: invalid character '/' in name 'share/my-file'
Fixes#50347
Previously the installPhase of the fixed ouput derivation would fail for
a package that has no markers, since `sed` would complain about having
no input files. If we use `find` instead of bash globs, that problem
goes away.
This avoids dumping -Wall warnings when they appear in framework
headers. As a result, we are closer to how regular headers are
included (via -isystem).
Also remove ccIncludeFlag lookup, this was unused & not very useful.
mergeInputs is now simply defined in terms of `concatLists` and
`catAttrs` instead of a more complicated `foldr`.
Note that the order of PATH has also changed. For example running the
following with nix-shell:
let
pkgs = import <nixpkgs> {};
shell1 = pkgs.mkShell {
buildInputs = [ pkgs.htop ];
};
shell2 = pkgs.mkShell {
buildInputs = [ pkgs.hello ];
};
shell3 = pkgs.mkShell {
inputsFrom = [ shell1 shell2 ];
buildInputs = [ pkgs.tree ];
};
in shell3
Results in the following PATH:
$ echo $PATH
...
/nix/store/yifq4bikf7m07160bpia7z48ciqddbfi-tree-1.8.0/bin:
/nix/store/vhxqk81234ivqw1a7j200a1c69k8mywi-htop-2.2.0/bin:
/nix/store/n9vm3m58y1n3rg3mlll17wanc9hln58k-hello-2.10/bin
...
Previously the order was:
/nix/store/n9vm3m58y1n3rg3mlll17wanc9hln58k-hello-2.10/bin
/nix/store/vhxqk81234ivqw1a7j200a1c69k8mywi-htop-2.2.0/bin:
/nix/store/yifq4bikf7m07160bpia7z48ciqddbfi-tree-1.8.0/bin:
I think the new order makes more sense because it allows to override
the PATH in the outermost mkShell.
Running the following expression with nix-shell:
let
pkgs = import <nixpkgs> {};
shell1 = pkgs.mkShell {
shellHook = ''
echo shell1
'';
};
shell2 = pkgs.mkShell {
shellHook = ''
echo shell2
'';
};
shell3 = pkgs.mkShell {
inputsFrom = [ shell1 shell2 ];
shellHook = ''
echo shell3
'';
};
in shell3
Will now results in:
shell2
shell1
shell3
Note that packages in the front of inputsFrom have precedence over
packages in the back. The outermost mkShell has precedence over all.
The previous behaviour would work fine as long as `symlink` is a link to
a file. If is a link to a directory though, the new `ln` wouldn't
overwrite it but would create a new link *in that directory* (with the
name of the link source).
Instead, we can precompute the target location, then first remove the
symlink and write the new one in its place.
