new-build silent failure on zip-archive-0.3.0.2

[dagit]

Building an executable that depends on zip-archive-0.3.0.2 fails at the configuration step.

$ cabal new-build
In order, the following will be built (use -v for more details):
zip-archive-0.3.0.2
pandoc-1.17.0.3
pandoc-citeproc-0.9.1.1
hakyll-4.8.3.0
blag-0.1.0.0
Configuring zip-archive-0.3.0.2...

It's noteworthy that zip-archive uses a custom Setup.hs. I suspect (although, haven't really tested much) that the Setup.hs is not compatible with the new-build. The bug here (from cabal's perspective) seems to be that it's a silent error.

zip-archive appears to work with the old style build command.

[gbaz]

A few things jump out at me as unique here. First, that there is custom build type with a Setup.lhs rather than Setup.hs. Second, here is the Setup.lhs file itself, on the off chance that the hooks stuff is to blame....

#!/usr/bin/env runhaskell

> module Main ( main ) where
>
> import Distribution.Simple
> import Distribution.Simple.Program
>
> main :: IO ()
> main = defaultMainWithHooks simpleUserHooks
>        { hookedPrograms = [ simpleProgram "zip" ]
>        }

[lspitzner]

Afaik the missing error output is a known bug (although i cannot find a specific open issue..). The typical workaround is -j1.

The error in this case looks roughly like:

/usr/bin/ghc
  --make
  -fbuilding-cabal-package
  -odir $PWD/dist-newstyle/build/zip-archive-0.3.0.2/setup
  -hidir $PWD/dist-newstyle/build/zip-archive-0.3.0.2/setup
  -i
  -i$PWD/.
  -optP-include
  -optP$PWD/dist-newstyle/build/zip-archive-0.3.0.2/setup/setup_macros.h
  -hide-all-packages
  -no-user-package-db
  -package-db $HOME/.cabal/store/ghc-7.10.3/package.db
  -package-db $PWD/dist-newstyle/packagedb/ghc-7.10.3
  -package-id Cabal-1.24.0.0-a42471777a73a03da1020057a8295e49190ec4361fbf2831ed81b97ce209ad9a $PWD/dist-newstyle/build/zip-archive-0.3.0.2/setup/setup.hs
  -o $PWD/dist-newstyle/build/zip-archive-0.3.0.2/setup/setup
  -threaded

$PWD/dist-newstyle/build/zip-archive-0.3.0.2/setup/setup.hs:1:1:
    Could not find module ‘Prelude’
    It is a member of the hidden package ‘base-4.8.2.0’.
    Perhaps you need to add ‘base’ to the build-depends in your .cabal file.
    Use -v to see a list of the files searched for.

So for some reason, setup is not built with base dependency.

lhs seems irrelevant.

This looks like a new-build bug to me. Still, as a workaround, adding

custom-setup
  setup-depends:
    base, Cabal

To zip-archive.cabal seems to work.

[hvr]

Smaller repro-case:

Name:                xxx
Version:             0
Cabal-Version:       >= 1.10
Build-type:          Custom

Executable Zip
  Buildable:         False
  Main-is:           Main.hs
  Build-Depends:     base

with a trivial default Setup.hs; NB: it's the Buildable: False that triggers this bug

[hvr]

@23Skidoo I'm quite sure this is 2f97657's fault (near mkDefaultSetupDeps)

[dcoutts]

The silent failure is likely due to the exception handling in build not being complete yet. I've got a patch and tests in the works for that.

As for the specific error with missing base, checking before/after 2f97657 sounds sensible. I'm reasonably sure I had examples like this working when I first implemented this bit. Shouldn't be too hard to track down.

Can use @hvr's example as an integration test. I've got some new integration tests comming. Using the code directly, not calling out to external cabal prog, so we can check we're getting the right exceptions etc.

[dcoutts]

Ok. I've identified the problem. It was indeed introduced in 2f97657. What it changed was that it added a addDefaultSetupDependencies policy into the standardInstallPolicy which was also being used by the new-build code (where we were already using our own use of addDefaultSetupDependencies with a different policy).

So I've got a fix, but I'll also take the opportunity to add integration tests that cover all four cases of setup in the new-build code paths.

[hvr]

@dcoutts do you mind publishing your fix somewhere, so that early adopters can apply it to their source-trees for testing? :-)

[dcoutts]

@hvr PR with tests available :-)

[ezyang]

Note that the lack of error messages still has not been fixed.

[dcoutts]

So this should be working now, both the original failure and the general lack of error reporting. If not, please re-open or open a new specific ticket.