fix(extra/rust): xcbuild requires 2 paths to be exposed by env #266
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Symptoms
The fix explained
xcbuild
on its own require 2 entries of$PATH
to be appended so thatrustc
, thuscargo build
, can see and usexcrun
via$PATH
Potential upstream fixes and alternative approaches
NixOS/nixpkgs#242431
But the PR will still likely not resolve this in an elegant way. The way
xcbuild
is structured, collocatingxcbuild
and itsxcrun
viasymlinkJoin
will fail the build due to sharing (iirc)/share
symlinks.How the traditional route of
pkgs.mkShell
works was via a hack of adding a string-path ontopropagatedBuildInputs
so that it gets added to environment variable.devshell
despises this approach in favor for minimal env viamkNakedShell
.Alternative approaches
Why an alternative approach? The current fix wishes for
pkgs.xcbuild
to coincide with the onerustc
uses. With the popularity of manyrust-overlay
s, this is very rarely the case. A drift of version is fine (for now), but it will require the end user to fetchxcbuild
twice, and may break in dep requirements (unlikely since xcbuild is archived. The following approaches take these potential pitfalls into account.a. I'm not confident enough for an attempt of refactoring
xcbuild
so that it is friendly for collocation withxcrun
. From the back of my mind, this will likely drastically change many dependent derivations. Evenxcbuild.withXcrun
would be a better solution that solves at the upstream level.b. Wiggle
mkNakedShell
, which I'm also not too confident in, to take into account ofpropagatedBuildInputs
and other pre-req derivations.c. A more bold approach is to just disregard
xcbuild
entirely and usexcrun
on our Rust environment. At the time of discovery, I didn't note this down in more details, so take this with a grain of salt.