new-build doesn't honor v1.6 cabal-spec build-dep semantics

[hvr]

In Distribution.Backpack.ConfiguredComponent there's

newPackageDepsBehaviourMinVersion :: Version
newPackageDepsBehaviourMinVersion = mkVersion [1,7,1]


-- In older cabal versions, there was only one set of package dependencies for
-- the whole package. In this version, we can have separate dependencies per
-- target, but we only enable this behaviour if the minimum cabal version
-- specified is >= a certain minimum. Otherwise, for compatibility we use the
-- old behaviour.
newPackageDepsBehaviour :: PackageDescription -> Bool
newPackageDepsBehaviour pkg =
   specVersion pkg >= newPackageDepsBehaviourMinVersion

However, operational-0.2.3.4 relies on this semantics and is currently broken under new-build:

$ cabal get operational-0.2.3.4 ; cd operational-0.2.3.4/
Unpacking to operational-0.2.3.4/
$ cabal new-build
Resolving dependencies...
In order, the following will be built (use -v for more details):
 - operational-0.2.3.4 {operational-0.2.3.4-inplace} (lib) (first run)
 - operational-0.2.3.4 {operational-0.2.3.4-inplace-operational-TicTacToe} (exe:operational-TicTacToe) (first run)
Configuring component lib from operational-0.2.3.4
Configuring component exe:operational-TicTacToe from operational-0.2.3.4
Preprocessing library operational-0.2.3.4...
Preprocessing executable 'operational-TicTacToe' for operational-0.2.3.4...
[1 of 1] Compiling Control.Monad.Operational ( src/Control/Monad/Operational.hs, /tmp/operational-0.2.3.4/dist-newstyle/build/x86_64-linux/ghc-8.0.1/operational-0.2.3.4/build/Control/Monad/Operational.o )
[1 of 2] Compiling Control.Monad.Operational ( src/Control/Monad/Operational.hs, /tmp/operational-0.2.3.4/dist-newstyle/build/x86_64-linux/ghc-8.0.1/operational-0.2.3.4/c/operational-TicTacToe/build/operational-TicTacToe/operational-TicTacToe-tmp/Control/Monad/Operational.o )

src/Control/Monad/Operational.hs:24:1: error:
    Failed to load interface for ‘Control.Monad.Identity’
    It is a member of the hidden package ‘mtl-2.2.1’.
    Perhaps you need to add ‘mtl’ to the build-depends in your .cabal file.
    Use -v to see a list of the files searched for.

src/Control/Monad/Operational.hs:25:1: error:
    Failed to load interface for ‘Control.Monad.Trans’
    It is a member of the hidden package ‘mtl-2.2.1’.
    Perhaps you need to add ‘mtl’ to the build-depends in your .cabal file.
    Use -v to see a list of the files searched for.

src/Control/Monad/Operational.hs:32:1: error:
    Failed to load interface for ‘Control.Monad.Reader.Class’
    It is a member of the hidden package ‘mtl-2.2.1’.
    Perhaps you need to add ‘mtl’ to the build-depends in your .cabal file.
    Use -v to see a list of the files searched for.

src/Control/Monad/Operational.hs:33:1: error:
    Failed to load interface for ‘Control.Monad.State.Class’
    It is a member of the hidden package ‘mtl-2.2.1’.
    Perhaps you need to add ‘mtl’ to the build-depends in your .cabal file.
    Use -v to see a list of the files searched for.

src/Control/Monad/Operational.hs:26:1: warning: [-Wunused-imports]
    The import of ‘Control.Applicative’ is redundant
      except perhaps to import instances from ‘Control.Applicative’
    To import instances alone, use: import Control.Applicative()
cabal: Failed to build exe:operational-TicTacToe from operational-0.2.3.4.

/cc @ezyang

[ezyang]

I'm guessing the problem is per-component build. If so, the problem should go away if you either (a) make it a Custom build type, or (2) configure and build the package by hand (using cabal configure/build or Setup configure/build) without per-component configuration.

[hvr]

@ezyang I can confirm that (a) in fact workarounds this. As this does in fact appear to be a bug in the per-component codepaths, does this mean you know how to fix this? :-)

[ezyang]

My inclination is to disable per-component build if cabal-version is 1.6 or earlier.

[hvr]

List of packages known to be affected:

• http://hackage.haskell.org/package/operational-0.2.3.4
• https://hackage.haskell.org/package/biopsl

[hvr]

jfyi, I'm testing the following patch locally:

--- a/cabal-install/Distribution/Client/ProjectPlanning.hs
+++ b/cabal-install/Distribution/Client/ProjectPlanning.hs
@@ -1140,6 +1140,11 @@ elaborateInstallPlan verbosity platform compiler compilerprogdb pkgConfigDB
             -- type, and teach all of the code paths how to handle it.
             -- Once you've implemented this, swap it for the code below.
             = fromMaybe PD.Custom (PD.buildType (elabPkgDescription elab0)) /= PD.Custom
+            -- cabal-format versions prior to 1.8 have different build-depends semantics
+            -- for now it's easier to just fallback to legacy-mode when specVersion < 1.8
+            -- see, https://github.com/haskell/cabal/issues/4121
+              && PD.specVersion pd >= mkVersion [1,8]
+
             {-
             -- Only non-Custom or sufficiently recent Custom
             -- scripts can be build per-component.

note that this changes the hashing since now even single-component cabal packages get demoted to legacy mode (if their spec version is older than 1.8); and there's quite a few VIP packages, such as mtl which fall into that category. So most of my nix-store gets invalidated by this patch!