[Hackage] #402: Automatic hoogle database for installed packages
Hackage
cvs-ghc at haskell.org
Mon Feb 14 03:51:32 CET 2011
#402: Automatic hoogle database for installed packages
---------------------------------+------------------------------------------
Reporter: Peaker | Owner: dschoepe
Type: enhancement | Status: assigned
Priority: normal | Milestone:
Component: cabal-install tool | Version: 1.2.3.0
Severity: normal | Keywords:
Difficulty: normal | Ghcversion: 6.8.3
Platform: |
---------------------------------+------------------------------------------
Comment(by duncan):
I applied the other patch about generating hoogle and html output in one
go. I've looked at this patch but I think it needs a bit more thought.
So, the general idea is to create a binary .hoo file for each package
right? Generating a merged binary database would be a separate task, not
covered by this patch. There are two issues:
1. The code in the doc step of cabal-install is assuming a certain layout
of the build tree by reading and writing files directly in the build tree.
This will not work for packages using build-type custom. It would be ok if
we were copying into a temporary image dir before doing the real
installation. In that case writing extra files into the temporary image
dir would be fine. As it is, I think this feature of generating a per-
package .hoo db would be better in the build system itself, in the Cabal
lib.
2. according to the
[http://www.haskell.org/haskellwiki/Hoogle#Database_Creation hoogle
manual], the .hoo files of dependencies need to be specified as well.
Since each .txt can be converted into a .hoo, and the final .hoo is not
really useful except as something to use to merge into a db that users
will actually use, perhaps it would be better to just generate the .txt
files per-package and then generate a big merged one. Alternatively, why
generate the .txt files if we could just generate the .hoo files?
Is there any point in generating both .txt and .hoo files for each
package?
More minor comments about the patch. It should use the existing framework
for running programs. This would cut down on the code and integrate it
properly with the Cabal exception handling and logging stuff.
--
Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/402#comment:7>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects
More information about the cabal-devel
mailing list