Ticket #4510 (closed bug: worksforme)
No links will be generated to these packages: base-4.3.0.0
| Reported by: | claus | Owned by: | igloo |
|---|---|---|---|
| Priority: | high | Milestone: | 7.2.1 |
| Component: | Compiler | Version: | 7.0.1 |
| Keywords: | Cc: | ||
| Operating System: | Windows | Architecture: | Unknown/Multiple |
| Type of failure: | None/Unknown | Difficulty: | |
| Test Case: | Blocked By: | ||
| Blocking: | Related Tickets: |
Description
As reported earlier, (point 6. in #4292), running haddock (via cabal) leads to missing documentation links. This was assumed fixed (comment:4:ticket:4292), but apparently not tested - the problem still exists (to reproduce, cabal-install anything that uses base types in its documentation, on top of a 7.0.1 windows install, with documentation enabled). As I can't see similar failures in hackage build reports, I guess the issue is Windows-specific.
From bug report to guessing at causes:
My current best bet is the occurrence of unescaped backslashes in filepaths in ghc-pkg fields (I seem to recall an implicit contract that these fields are supposed to be valid Haskell Strings?). As a general remark, using forward-slashes seems to be less error-prone.
Cabal (which generates these warnings, in Distribution/Simple/Haddock.hs) seems to parse these fields as Haskell Strings, and fails when doesFileExist can't find the .haddock interface file.
haddock-interfaces: $topdir/../doc/html/libraries/base-4.3.0.0\base.haddock
There are other fields in ghc-pkg output that have unescaped backslashes in file names (the *-dirs family), so apparently the Haskell String contract is just my imagination?
