Adds sublib support

[angerman]

This adds the sublib test. Execute with

nix build -f default.nix cabal-sublib --show-trace

and enjoy the gore!

Changing modules/plan.nix to:

@@ -53,7 +53,8 @@ with types;
 
       let m = if revision == null
               then (abort "${name} has no revision!")
-              else revision modArgs;
+              else revision (modArgs // { hsPkgs = hsPkgs // m.components.sublibs; });
       in m // { flags = lib.mapAttrs (_: lib.mkDefault) (m.flags // revArgs.flags or {}); }
     ) (lib.filterAttrs (n: v: v == null || v.revision != null ) module.packages);
   };

does get us a bit further. However, this results in the dependency to be a raw sublib instead of a package. And subsequently leads to breakage in the builder/comp-builder.nix.

[ElvishJerricco]

I don't think we want sublibs in the global package set, do we? Shouldn't we instead just augment the hsPkgs provided to each package to include its sublibs?

[angerman]

I don't think we want sublibs in the global package set, do we? Shouldn't we instead just augment the hsPkgs provided to each package to include its sublibs?

Right! That's precisely what I tried to get done properly :-)
See
https://github.com/input-output-hk/haskell.nix/pull/63/files#diff-b43b54fd141cefb908e8f8c428a5fa5f

[ElvishJerricco]

Shouldn't there only be one package per derivation? Why would there be multiple?

[angerman]

I think the issue is the all target. If you run the following on a cabal file with a sublibrary:

$ runghc Setup.hs configure # without component target, as we do for `all`.
$ runghc Setup.hs register --gen-pkg-config=pkg.conf

you end up with a folder for pkg.conf that contains the package configuration file for the library as well as the sublibrary.

If you don't have sublibraries, pkg.conf is your package configuration file.

[ElvishJerricco]

@angerman So this only comes up when a package depends on the all component? That shouldn't happen, should it?

[angerman]

Why should this not happen? Why wouldn't we build the all component? We do allow this right now (and the test case tried to do precisely that).

Thus, unless we want to remove the all component again, I'm afraid we'll need to keep this.

[ElvishJerricco]

@angerman The all component is, to my understanding, only for the sake of users who want a shell for all, plus the novel purpose of building all components in one derivation. The intention is that components will depend on components, not on any all derivation.