Addded support for ./doc, ./lib files, added (pre|post)Install support.

[Davorak]

With this commit ghc-wrappers will add ghc's documentation to
./nix-profile. ${ghc.version} is appended to the default documenation
folder so multiple ghc versions will not clobber each other.

Added support for preInstall and postInstall hooks.

[vcunat]

Good idea, I miss GHC's docs in my profile.

Isn't it better to symlink the directories rather than copy them? IMO they're in closure anyway, so it's a waste of space (until nix-store --optimize).

[peti]

Yes, thank you for this patch (which should probably go to stdenv-updates, because it causes a re-build of all Haskell packages).

I, too, think that symlinking the documentation would be better than copying it.

[vcunat]

Does changing just the wrapper really affect so many builds? I thought it should only affect environments.

If it does, maybe it would be sooner in master if we put this into x-updates. The thing is that stdenv-updates still needs a lot of fixing. This change (maybe) has the only problem that it affects a lot of packages. It might even be useful to have a branch for such changes, like master-stable (rare hash changes) and master-unstable (often hash changes); but maybe it would just complicate things...

[peti]

ghc-wrapper is used internally to build every Haskell package in Nix, so
it's a build input to everything else in haskellPackages_ghcXYZ. I
believe we can commit a change like this one directly to master -- the
number of re-builds is manageable, maybe a 1000 packages or so --, but
the patch should be polished, tested, and ready when we commit it,
because it wouldn't be nice to trigger those kind of re-builds more than
once.

Generally speaking, I believe that ghcWithPackages is superior for
generating a GHC environment for end-users, because it interacts nicely
with cabal-install. I have the following code in my
~/.nixpkgs/config.nix file:

let
  haskellEnv = haskellPackages: haskellPackages.ghcWithPackages (self: with haskellPackages; [
    # Haskell Platform
    async cgi fgl GLUT haskellSrc html HTTP HUnit mtl network OpenGL
    parallel parsec QuickCheck random regexBase regexCompat regexPosix
    split stm syb text transformers vector xhtml zlib cabalInstall alex
    haddock happy primitive
    # other packages
    cmdlib dimensional funcmp hackageDb hledger hledgerLib hlint hoogle
    HStringTemplate monadPar pandoc smallcheck tar uulib permutation
    xmonad xmonadContrib xmonadExtras xmobar
  ]);
in
{
  packageOverrides = pkgs:
  {
    ghcDevEnv = haskellEnv pkgs.haskellPackages_ghc762;
  };
}

This approach also makes all documentation available in the generated profile.

[vcunat]

Hmm, so why don't we make ghcWithPackages the default thing for user envs and add documentation only there... because for internal compilation it's useless anyway, right?

[peti]

I have wanted to switch pkgs/build-support/cabal/default.nix from
ghc-wrapper to ghcWithPackages for a while now, but haven't done it so
far. We have internal issues with ghc-wrapper as well. Some packages
rely on the ghc-paths library to find the paths to certain compiler
components. That mechanism won't work with ghc-wrapper, which results in
broken builds and/or test suite runs. ghcWithPackages interacts more
nicely with ghc-paths, so it would be superior for internal use, too.
IMHO, it's just a matter of time before we get rid of ghc-wrapper
internally, too.

The biggest advantage of ghc-wrapper is that it's very simple to use.
It's possible to install any Haskell library into a profile, and a GHC
binary from that same profile will find it. That's nice, user-friendly
behavior. ghcWithPackages, on the other hand, forces users to write a
Nix expression to use GHC, which is kind of inconvenient.

[vcunat]

OK, so I propose the following to do at the moment: split internal and user-env ghc-wrapper, and modify only the user-env one by this patch to include docs etc.

[peti]

Yes, that sounds like a good solution.

[Davorak]

So in the commit below I create an outer wrapper and system link the documentation and lib folders. This keeps the installation command for ghc the same and prevents needing to rebuild haskell packages.

Davorak@c11972a

However it seems like there should be a better way of doing outer-wrapper.nix, if you could take a look and offer improvements I would appreciate it.

[peti]

You cannot change the haskellPackages.ghc attribute if you want to avoid re-builds, because that's what the cabal builder is referring to for internal builds. With this patch applied, all builds are run with the "outer-wrapper", which is what we wanted to avoid IMHO.

[peti]

I pushed an edited version of your changes in commit 3bf0d2b. Please let me know if there is any trouble.