[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: 
  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
  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

 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