Skip to content
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.

Sign up for GitHub

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

Jump to bottom

haskell: fix package sets based on integer-simple #43367

Merged
merged 1 commit into from Jul 11, 2018
Merged

haskell: fix package sets based on integer-simple #43367

merged 1 commit into from Jul 11, 2018

Conversation

dtzWill
Copy link
Member

@dtzWill dtzWill commented Jul 11, 2018

Fixes mass build failures in these package sets,
due to "unknown pacakge: integer-simple".

Attributes that demonstrate this (see before/after):

  • haskell.packages.integer-simple.ghc843.hello
  • haskell.packages.integer-simple.ghc802.scientific

The second one is from the NixOS manual, FWIW.

  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Fits CONTRIBUTING.md.

Truth be told this change was an "educated guess" of sorts,
while debugging why none of these packages would compile.

It seems reasonable to me, but I don't have much of an argument
for why it is a good change other than "it fixes things".

@dtzWill
haskell: fix package sets based on integer-simple
da1e98d 
Fixes mass build failures in these package sets,
due to "unknown pacakge: integer-simple".

Attributes that demonstrate this (see before/after):

* haskell.packages.integer-simple.ghc843.hello
* haskell.packages.integer-simple.ghc802.scientific

The second one is from the NixOS manual, FWIW.
@matthewbauer
Copy link
Member

matthewbauer commented Jul 11, 2018 •
edited

This shouldn't be necessary. You should be able to bootstrap simple integer GHC without a GHC using GMP. I wonder if the issue is that integer-simple = null thing being applied to early?

Off-topic but this integer-simple attribute set seems like a bad idea. My impression was that you should just be able to do overrides to accomplish the same thing. Doesn't GHC give the builtin simple-integer precedence in something like this?

@dtzWill
Copy link
Member Author

dtzWill commented Jul 11, 2018 •
edited

I honestly don't know-- FWIW the compilers build successfully, and ghc-pkg list|grep integer shows they have integer-simple (and not integer-gmp) but for whatever reason this is not the case when building the packages themselves (nix-shell'ing into such an environment and running same ghc-pkg command shows integer-gmp now instead of integer-simple).

As I'm writing that, I realize i didn't check where ghc-pkg came from in the shell env, will check...

Yep! The normal (integer-gmp) GHC is what's on PATH (and in depsBuildBuild) before this change, after it's the integer-simple GHC.

Not sure if that helps? :)

@dtzWill
Copy link
Member Author

dtzWill commented Jul 11, 2018

cc @nh2 -- somewhat relevant for static linking, especially re:any issues encountered using libgmp (technical or due to licensing (?)).

Might make sense to have a GHC with dependencies containing static libraries (perhaps in addition to shared ones) to make it easier to statically link... things like gmp/zlib/ncurses (and libc if using glibc?).

Anyway the other PR I submitted today is likely much more relevant, ping incoming :).

@dtzWill
Copy link
Member Author

dtzWill commented Jul 11, 2018

cc @Ericson2314 -- do you have any insights into why this might be good/bad/needed/not ? :)

@Ericson2314
Copy link
Member

I think this actually is needed. buildHaskellPackages just affects how build tools and Setup.hs is built, not now GHC is built. That, very confusingly, is bootPkgs, which is passed to each GHC. Unless it's cross the GHCs will shadow each other, and should be the same anyways. Let me check.

@Ericson2314
Copy link
Member

Yeah that's it.

@Ericson2314 Ericson2314 merged commit ee9eeea into NixOS:master Jul 11, 2018
@nh2
Copy link
Contributor

nh2 commented Jul 13, 2018

cc @nh2 -- somewhat relevant for static linking, especially re:any issues encountered using libgmp (technical or due to licensing (?)).

Might make sense to have a GHC with dependencies containing static libraries (perhaps in addition to shared ones) to make it easier to statically link... things like gmp/zlib/ncurses (and libc if using glibc?).

@dtzWill That sounds pretty fantastic -- it feels like the right path forward is to first make building Haskell fully statically easy with nix in master, and then step by step ensure that all the native deps also play along nicely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@Ericson2314 Ericson2314 Ericson2314 approved these changes

Assignees
No one assigned
Labels
6.topic: haskell 10.rebuild-darwin: 0 10.rebuild-linux: 0
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
5 participants
@dtzWill @matthewbauer @Ericson2314 @nh2 @GrahamcOfBorg