commercialhaskell / commercialhaskell/stack
`--haddock-executables` index does not distinguish `Main` modules
- Dominant language
- Haskell
- Stars
- 4.1k
- Forks
- 850
- Avg merge
- 10h 37m
- Merged PRs (30d)
- 4
Description
Version 2.16.0, Git revision 1817292f22987cc764a72146cf707f028c575bf5 (10654 commits) PRE-RELEASE x86_64 has `--haddock-executables` (built on top of Cabal (the library)'s `haddock --executables`), but there are problems with the index.
Consider a two-package project (`packageA`, `packageB`) each with two executable components (eg `packageA-exe1`, `packageA-exe2`). The index generated for project packages has four links to `Main` but all of them are to the `Main` of `packageB-exe1`.
Using `haddock --show-interface` reveals that all four `*.haddock` files commence:
~~~json
{"link_env":{"$main$Main$main":"Main", ...
~~~
That can be contrasted with the two `*.haddock` files for the main library:
~~~json
{"link_env":{"$packageA-0.1.0.0-ErEp6QMCDA5L7wclG18d4W$Lib$someFunc":"Lib"}, ...
~~~
and
~~~json
{"link_env":{"$packageB-0.1.0.0-LJmkqLQIxknEQ7YIpA65Ah$Lib$someFunc":"Lib"}, ...
~~~
`--cabal-verbosity 3` reveals that, with the main library, Cabal (the library) invokes Haddock with options that include:
~~~text
packageA> --optghc=-this-unit-id
packageA> --optghc=packageA-0.1.0.0-ErEp6QMCDA5L7wclG18d4W
packageB> --optghc=-this-unit-id
packageB> --optghc=packageB-0.1.0.0-LJmkqLQIxknEQ7YIpA65Ah
~~~
There is no equivalent for when Cabal invokes Haddock for the executable components.
Contributor guide
Assessment
This issue has not been assessed yet.