ghc: support building with integer-simple

[basvandijk]

If the flag enableIntegerSimple is true GHC will be build with the GPL-free but slower integer-simple library instead of the faster but GPLed integer-gmp library.

[basvandijk]

I also added some documentation to the manual.

[basvandijk]

A few questions:

• Should we give names to the compilers build with integer-simple? Advantages are that we can then easily build them on hydra and users can more easily select those compilers without resorting to overriding. Maybe we can use a naming scheme like: pkgs.haskell.compiler.ghc802.integer-simple or pkgs.haskell.compiler.integer-simple.ghc802.

• Secondly, should we also provide package sets for these compilers?

• Finally, should we build these compilers and/or package sets on hydra or will this increase the load to much?

@peti any ideas?

[basvandijk]

I pushed another commit that answers my first and second questions. I provide convenient names ro get a GHC compiler build with integer-simple and to get a package set supporting integer-simple:

The attribute pkgs.haskell.compiler.integer-simple."${ghcVersion}" provides a GHC compiler build with integer-simple.

Similarly, the attribute pkgs.haskell.packages.integer-simple."${ghcVersion}" provides a package set supporting integer-simple.

[peti]

This is some fine work. Thank you very much for the contribution.

I've merged the patches to haskell-updates. This means that Hydra will test-build everything at http://hydra.nixos.org/jobset/nixpkgs/haskell-updates. I'll merge the patches to master in a day or two -- assuming that the changes don't break the compiler builds. :-)

[basvandijk]

Thanks Peter.

Do you think it makes sense to set recurseForDerivations = true in pkgs.haskell.compiler.integer-simple causing the underlying compilers to be build by hydra?

Offtopic: I would also prefer to have a binary cache available for packages build with profiling (enableLibraryProfiling = true;). At LumiGuide we currently have a hydra job which builds all our Haskell packages and their dependencies with profiling enabled in case we quickly need to profile something.

[vcunat]

The jobset status looks OK. Mergeable then?

(I'd like all larger rebuilds merged now to staging so it can be stabilized without too much rebuilding.)

[peti]

Do you think it makes sense to set recurseForDerivations = true in pkgs.haskell.compiler.integer-simple causing the underlying compilers to be build by hydra?

I pushed a commit that does that in 47a604a41807dd4221a354a095715c7320008d6e. I think we'll use that for running test builds right now, but it's probably overkill to enable those builds on hydra.nixos.org for all GHC versions we have. Who needs GHC 7.2.2 anyway -- with or without gmp? GHC is relatively expensive to compile and to store (the resulting package is >1 GB), so I'd rather be cautious about enabling too many builds that we probably don't need anyway. I do think that it is appropriate to enable the gmp-less variant of the latest ghc in pkgs/top-level/release.nix though.

I would also prefer to have a binary cache available for packages build with profiling (enableLibraryProfiling = true;).

#22340

[peti]

@vcunat, give us one more day, please. I have one minor change I'd like to see implemented before we commit.

[peti]

This list contains every compiler we have except 7.0.4, I believe. Assuming that newer versions released in the future will probably support this feature, too, would it make sense to invert this logic, i.e. to list those compilers that don't support a gmp-less build? That would make this list shorter and it would remove the need to do manual maintenance in the future because new compiler versions are implicitly supported the moment we add them.

[basvandijk]

@peti something like this:

LumiGuide@ae72fef

[peti]

Very cool, thank you. Added to haskell-updates in a7fffbf808572d1afd40a10f644eb213116a3bad.

[vcunat]

OK, in case Hydra gets idle, we can "build staging first" and eventually even exchange the merge order.

[peti]

The integer-simple variant of GHC 7.6.3 does not compile: http://hydra.nixos.org/build/47389866/nixlog/1/raw. There is some code that expects functions like divInteger which appear to be missing.

[peti]

@vcunat, dfcc9e2 and 75a4679 pushed to staging.

[basvandijk]

@peti regarding GHC-7.6.3, maybe it's best to put "ghc763" in integerSimpleExcludes.