Create offline haddocks including all dependencies, with an index

[nomeata]

I am about to embark on a flight, and I was expecting that a call like

cabal new-haddock

would build the haddock of my current project and all its dependencies (which may not have haddocks yet), and also create a nice index akin to file:///usr/share/doc/ghc-doc/html/libraries/index.html with the haddocks of all visible packages. But it seems that this is not yet supported.

(I am not sure if #3535 is about this, or merely about a technical detail on the road to this feature.)

[sjakobi]

With the patch from #5395 I can build haddocks including dependency haddocks with

cabal new-haddock --enable-documentation

I don't quite understand why I need to add the --enable-documentation flag but I guess that's a different topic.

[k0001]

Since cabal new-* embraces the idea of multiple packages per project, it would be great if we could have something like standalone-haddock building a top-level documentation for our project encompassing the haddocks for all modules of all the packages in our project.

[ip1981]

I'm not sure I totally understood you guys, but I miss the feature of creating a haddock documentation for all modules used in project, and I want this documentation in a single directory with all local relative links. So that I could put it in a tarball, publish in Jenkins, etc. I was able to do so with another s-tool ;). There is an option --haddockdir=, but I could find its effect. I'm with Cabal 2.4.0.1

[ChristopherKing42]

@k0001 And maybe for efficiencies sake symbolic links could be used to share documentation between packages (when identical).

[harendra-kumar]

Is anyone working on/interested in this?

[nomeata]

Not working on it, but certainly interested :)

[isovector]

I'm just switching over to cabal from stack, and came across the need to do this. Is this still unsupported? Is there some work around?

[geekosaur]

As I see it, the big problem here is that every build plan potentially has its own distinct documentation tree. So documentation for any given dependency can be (and is, with documentation: True) built and saved in the store, but the index would need to be per project and would change with the build plan. This doesn't happen with stack unless you make heavy use of extra-deps and don't constrain it to specific versions (note that stack specifically recommends that you do so constrain it).