cabal haddock fails with internal libraries

[shlevy]

When using internal libraries, cabal haddock seems to fail unconditionally:

$ cabal haddock
Preprocessing library 'internal' for internal-library-test-0.1.0.0..
Running Haddock on library 'internal' for internal-library-test-0.1.0.0..
Haddock coverage:
   0% (  0 /  2) in 'Internal'
  Missing documentation for:
    Module header
    foo (internal/Internal.hs:3)
Documentation created: dist/doc/html/internal-library-test/index.html
Preprocessing library for internal-library-test-0.1.0.0..
Running Haddock on library for internal-library-test-0.1.0.0..
cabal: internal error when calculating transitive package dependencies.
Debug info: []

[23Skidoo]

See also #4215, #1085 and #1919. Would be nice to fix all these in one go...

[hvr]

fwiw, I managed to generate haddocks back then in July for http://hackage.haskell.org/package/haddock-library

EDIT: I just tried again (with cabal HEAD), it still works just fine!

$ cabal get haddock-library-1.4.5 && cd haddock-library-1.4.5

$ cabal new-haddock --haddock-for-hackage

results in https://gist.github.com/3d1c22e67a75c3e7117f64b8a03d7a3b

[23Skidoo]

Hmm, so broken only with old-build? Interesting.

[shlevy]

Is the plan to not fix this and wait for new-haddock?

[ezyang]

Yeah, I'm pretty OK with just saying "use new-build" for this one.

[peti]

~
$ runhaskell Setup.hs new-haddock
unrecognised command: new-haddock (try --help)
~

Now what?

This bug is quite nasty and it effectively prevents all kinds of distributors like Nix and openSUSE from generating Haddock documentation for any package that uses an internal library. :disappointed:

[hvr]

@peti There's not going to be a Setup.hs new-haddock just as there isn't going to be a Setup.hs new-build command, as that's a low-level interface (c.f. "plumbing" in the Git model) which cabal new-haddock (the "porcelaine") builds upon.

TLDR, you need to invoke Setup.hs haddock for each component individually, similiar to how cabal new-haddock does.

[peti]

You need to invoke Setup.hs haddock for each component individually, similiar to how cabal new-haddock does.

It would be super nice if runhaskell Setup.hs haddock would to that for me. I realize that is a decent work-around for an issue the old(er) Cabal code has, but still it feels awkward that I (and all other people who want to distribute Haskell packages to end-users) now have to implement this work-around in our build infrastructure. If we'd just get a fixed version of Cabal, then this issue would be flat-out solved for everyone.

[hvr]

It would be super nice if runhaskell Setup.hs haddock would to that for me.

Well, I'm not saying we wouldn't welcome a patch for that. But please understand the priority for some of us here is getting the overdue cabal new-build feature out of the door to become cabal's default mode of operation; so we somewhat lack the bandwidth to address things (especially when they appear like issues which may become obsolete/moot by cabal new-build anyway) ourselves that don't contribute to that goal and may even cause further delays.

[shlevy]

@hvr So if I'm understanding correctly, in the example above we could do Setup haddock internal then Setup haddock and all would be well?

[peti]

@hvr,

You need to invoke Setup.hs haddock for each component individually.

I tried to do that, but I couldn't figure out what exactly you mean. The haddock command does not take any argument that indicates which component to process:

~~~
$ runhaskell Setup.hs haddock --help
Generate Haddock HTML documentation.

Usage: Setup.hs haddock [FLAGS]
...
~~~

Now, there are flags that I could pass, but none of them seem to do what you suggested we should do. If you have the chance, could you please post a slightly more verbose explanation or maybe even a complete example of how to build the documentation for, say stylish-cabal-0.4.0.0 with the normal Setup haddock command?

[nrolland]

Any work-around for haddock-library when using stack ? haddock-library-1.5.0.2 is on LTS-12.20, which is potentially used by many, and it breaks the documentation generation for an entire project AFAICT, unlike nixpkgs which just dontHaddock the culprits