On 19 August 2010 21:15, Andrew Coppin
Daniel Fischer wrote:
Yes, when cabal runs haddock on a package, it generates a comprehensive index if none is present or expands it with the new docs. Quite cool that :)
It's something I've always _wanted_ Cabal to do, but this is the first time I've ever seen it happen. I don't know what particularly I did to make this happen, and now it seems to be gone, so...
If you have documentation enabled then it is recreated every time you install a package. (Though only for user packages, since we have not yet worked out somewhere sensible we can stick a global index).
I gathered. Apparently there's no "cabal uninstall" or even merely a "cabal unregister" yet... (There must surely be a ticket for that already?)
Yup, there's a ticket for it.
Well, the worst thing that can happen is I get no documentation, which isn't exactly a disaster. I'm just wondering how these files got created to start with; adding more packages doesn't appear to recreate it. I suppose I could try reinstalling all of them...
If you have documentation enabled (ie use --enable-documentation on the command line, or have "documentation: True" in the ~/.cabal/config file) then docs get created for each package you install, and the haddock index/contents of all installed docs gets updated.
Then again, all the links were broken anyway. They all had paths like "C:\Program Files\Haskell\...whatever", and Mozilla apparently expects them to say "file://C:/Program Files/Haskell/...whatever". It kept whining that "the C:\ protocol is not registered"
Apparently, haddock links to absolute paths. That's of course not the right thing to do if the path begins with an invalid protocol specifier ("C:"). And it's annoying if you want to move the docs.
I imagine it's so that each package can be placed in a completely arbitrary place in the filesystem, and the links still work. I'd actually be surprised if these URLs work on Linux either; they don't appear to follow the requisit web standards.
You may be right, or perhaps URL syntax is just liberal enough to let unix style paths work. It's still a bug of course that we're not using the file:// protocol which makes it not work on windows. I filed it here: http://hackage.haskell.org/trac/hackage/ticket/516#comment:6 Duncan