Daniel Fischer wrote:
On Wednesday 18 August 2010 19:13:48, Andrew Coppin wrote:
On that note, I just remembered something else: During the course of playing with all this Cabal stuff, I discovered that I had somehow acquired a global package index. As in, an HTML file that links to the documentation of *all* installed packages, not just the ones that come with GHC. And when I installed more packages, it seemed to add them to this index.
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...
Alas, removing packages doesn't remove them.
Since cabal isn't involved in removing packages, that can't be done.
I gathered. Apparently there's no "cabal uninstall" or even merely a "cabal unregister" yet... (There must surely be a ticket for that already?)
I tried deleting the file to see if Cabal would rebuild it, and now I just have no file at all, and no idea how to get it back.
Generally, until you know it's safe to delete, move or rename first, so if something breaks, it's not gone for good.
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...
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.