[Nix-dev] A Journey into the Haskell NG infrastructure: Part I

[Peter Simons]

Hi Benno,

 > I wonder if it would be possible to just use ghcWithPackages in
 > generic-builder.nix too?

yes, that's possible. Since we have that environment in the 'env'
attribute anyway, it wouldn't be a big change in terms of code either.


 > That way, the symlinking logic does not have to be duplicated.

I'm not sure which symlinking logic you're referring to? Do you mean the
part of generic-builder.nix that collects package.conf files to build a
package.conf.d directory for the build? If that's what you meant, then
yes, we could drop that from the builder. This would save only 3-4 lines
of code, though, because we'd still have to traverse the build inputs to
compute the --extra-{include,library}-dirs flags for "cabal configure".
Building the package.conf.d directory is just a small part of that loop.


 > If we set the NIX_GHC_* variables for GHC-paths then packages will
 > find their libraries even if they use the GHC API.

I'm not sure what you mean. Where exactly should we set those variables?


 > Are there any disadvantages to that approach which I have missed?

Well, this change doubles the amount of store paths required for Haskell
builds, because for every derivation that you compile, you create
another derivation with the environment to compile it. Those can be
gargabe collected, eventually, but at build time we'd create a lot of
cruft. This would also mean that any change to the wrapper code would
trigger a re-build of every Haskell package.


 > Another benefit would be that there is no need for a separate env
 > target in this setup, running nix-shell on the real expression will
 > just work.

Yes, that is true.

Best regards,
Peter