Ticket #284 (closed defect: invalid)

Opened 10 months ago

Last modified 9 months ago

Haddock fails with "Module defined in multiple files"

Reported by: jhenahan Owned by: Fūzetsu
Priority: critical Milestone:
Version: 2.14.0 Keywords: osx clang
Cc: ekmett@…

Description

I've been mucking around with 7.8 RC2, and I've been hitting some issues of the form

<no location info>:
    module ‘pkgid-pkgversion:Main’ is defined in multiple files: dist/build/tmp-#####/Stuff

I asked about this on IRC, and Brandon Allbery (geekosaur) suggested

18:38 <geekosaur>| I suspect there's a different Main for
different platforms with some trickery to make the right one be
used; haddock doesnt handle that kind of thing very well, IIRC
18:40 <geekosaur>| that, or you somehow have two different builds
of the same version of Cabal, but then why does it have a Main
module since it's a library. unless it's actually a test program
and haddock probably shouldn't even be looking at it... that would
be a bug to report, I think
18:40 <geekosaur>| not really enough information to say

This has been causing some builds to fail for me when documentation generation fails. Some libraries generate documentation correctly, but a number of (for instance) cabal-install dependencies fail to.

CPU: 8-core 64-bit sandybridge
OS X: 10.9.2-x86_64
Xcode: 5.0.2
CLT: 5.0.1.0.1.1382131676
Clang: 5.0 build 500
GHC: 7.8.0.20140228
Haddock: 2.14.0

Libraries known to fail building documentation with this error:

Cabal 1.19.2 (github)
parsec-3.1.5 (hackage)
network-2.4.2.2 (hackage)
zlib-0.5.4.1 (hackage)

random-1.0.1.1 (hackage) fails with

System/Random.hs:2:2: parse error on input ‘#’

but I'll file a separate issue if this is not already known.

Change History

  Changed 10 months ago by Fūzetsu

Can you come up with a smaller example than such big packages like Cabal, parsec, network and zlib? Is the failure consistent if you try to install any of these inside of the sandbox? This could be a cabal bug/oversight although I'm completely unsure.

The random failure seems like a CPP issue (maybe?). Please file as a separate issue with a minimum example.

follow-up: ↓ 3   Changed 10 months ago by Fūzetsu

Oh, one more thing, does it happen with an older version of Haddock, such as the one that comes with 7.6.3?

in reply to: ↑ 2   Changed 10 months ago by jhenahan

Replying to Fūzetsu:

Oh, one more thing, does it happen with an older version of Haddock, such as the one that comes with 7.6.3?

With Haddock 2.13.2 and GHC 7.6.3, the issue is not present.

  Changed 9 months ago by Fūzetsu

  • owner set to Fūzetsu
  • priority changed from major to critical
  • status changed from new to assigned

Just had another report of this, this is a pretty big deal if it happens to many people rather than being an isolated case.

  Changed 9 months ago by ekmett

  • cc ekmett@… added

This is also affecting me on a couple of projects.

GHC 7.8.1rc2 on Mac OS X Mavericks with XCode 5, it happens with either an older haddock compiled before upgrading or with the ghc 7.8 branch of haddock when go to haddock free.

In my case there are not multiple Main files, it is just pretending the the dozen or so normal Haskell files in the package are named Main!

This is code that was pretty widely installed before 7.8. It continues to haddock fine on GHC 7.6.3.

  Changed 9 months ago by duncan

  • keywords osx clang added

I worked with someone on IRC a few days back who had these symptoms.

We worked out that cpp was producing empty output files and ghc (haddock via ghc api) then interprets those files as Main modules (since they lack a module decl).

That user was on OSX, and so I strongly suspect the problem is yet another of these OSX clang / gcc/cpp issues.

If I recall correctly, it was cabal that was calling cpp in this case (though I could be wrong). What is odd is that whoever is calling cpp is not noticing any exit code. Of course it could be that the borked cpp is just not returning any non-0 exit code.

  Changed 9 months ago by thoughtpolice

This can currently be worked around by passing --ghc-options=-optP-P to cabal haddock, FWIW.

  Changed 9 months ago by hvr

fyi, see also haskell/cabal#1740 for possibly working around this in Cabal

  Changed 9 months ago by Fūzetsu

  • status changed from assigned to closed
  • resolution set to invalid

I'm going to close as invalid here considering it's not a Haddock bug but a GHC one with workarounds in the above Cabal issue. Thanks everyone for investigating this.

Note: See TracTickets for help on using tickets.