New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stdenv, haskell: bonafied GHCJS cross compilation without stdenv.cc for 19.09 #76545
Merged
Ericson2314
merged 22 commits into
NixOS:release-19.09
from
obsidiansystems:ghcjs-cross-without-cc-19.09
Dec 31, 2019
Merged
stdenv, haskell: bonafied GHCJS cross compilation without stdenv.cc for 19.09 #76545
Ericson2314
merged 22 commits into
NixOS:release-19.09
from
obsidiansystems:ghcjs-cross-without-cc-19.09
Dec 31, 2019
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Before, we'd always use `cc = null`, and check for that. The problem is this breaks for cross compilation to platforms that don't support a C compiler. It's a very subtle issue. One might think there is no problem because we have `stdenvNoCC`, and presumably one would only build derivations that use that. The problem is that one still wants to use tools at build-time that are themselves built with a C compiler, and those are gotten via "splicing". The runtime version of those deps will explode, but the build time / `buildPackages` versions of those deps will be fine, and splicing attempts to work this by using `builtins.tryEval` to filter out any broken "higher priority" packages (runtime is the default and highest priority) so that both `foo` and `foo.nativeDrv` works. However, `tryEval` only catches certain evaluation failures (e.g. exceptions), and not arbitrary failures (such as `cc.attr` when `cc` is null). This means `tryEval` fails to let us use our build time deps, and everything comes apart. The right solution is, as usually, to get rid of splicing. Or, baring that, to make it so `foo` never works and one has to explicitly do `foo.*`. But that is a much larger change, and certaily one unsuitable to be backported to stable. Given that, we instead make an exception-throwing `cc` attribute, and create a `hasCC` attribute for those derivations which wish to condtionally use a C compiler: instead of doing `stdenv.cc or null == null` or something similar, one does `stdenv.hasCC`. This allows quering without "tripping" the exception, while also allowing `tryEval` to work. No platform without a C compiler is yet wired up by default. That will be done in a following commit.
This platform doesn't have a C compiler, and so relies and the changes in the previous commit to work.
This is GHCJS, and perhaps other obscure targets.
js-ghcjs didn't fit in an existing categor.
js-ghcjs didn't fit in an existing categor.
…oss-without-cc-19.09
Use `buildPackages.stdenv.mkDerivation` because we are making a shell script to start hoogle on the build platform.
This is a bit dubvious, but the alternative of making nodejs a nativeBuildInput for node packages is worse. In general the cross story for interpreted languages is murky, and this fits that pattern.
This makes us a bit more robust to various splicing nastiness. May splicing someday go so we don't have to resort to such hacks.
(cherry picked from commit 59dbb00)
Otherwise it passes `--with-ghc=ghc`, and we do the wrong thing.
Ericson2314
requested review from
basvandijk,
edolstra,
matthewbauer and
nbp
as code owners
December 26, 2019 17:38
ofborg
bot
added
6.topic: haskell
6.topic: stdenv
Standard environment
10.rebuild-darwin: 0
10.rebuild-linux: 0
labels
Dec 26, 2019
Ericson2314
changed the title
stdenv, haskell: bonafied GHCJS cross compilation without stdenv.cc
stdenv, haskell: bonafied GHCJS cross compilation without stdenv.cc for 19.09
Dec 30, 2019
… into ghcjs-cross-without-cc-19.09
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
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.
Motivation for this change
Back-port of #74090
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)Notify maintainers
cc @