[Hackage] #187: Paths_pkgname module is hard to use in a library

Hackage trac at galois.com
Fri Dec 7 15:18:08 EST 2007

#187: Paths_pkgname module is hard to use in a library
  Reporter:  duncan           |        Owner:         
      Type:  defect           |       Status:  new    
  Priority:  normal           |    Milestone:         
 Component:  Cabal            |      Version:
  Severity:  normal           |     Keywords:         
Difficulty:  easy (<4 hours)  |   Ghcversion:  6.8.1  
  Platform:  Linux            |  
 Most users of the auto-generated {{{Paths_pkgname}}} module are programs.
 With GHC at least they can get away with not specifying the
 {{{Paths_pkgname}}} in the {{{Other-Modules}}} field. Get away with in the
 sense that it does not lead to linker errors because {{{ghc --make}}} does
 dependency chasing and links in all the necessary .o files.

 However for a library you must specify every module in {{{Exposed-
 Modules}}} or {{{Other-Modules}}} or one does get linker errors when you
 try to use the packages. That's because the missing module's .o files will
 not have been included in the library .a archive. See bug #128.

 So for a library one must specify {{{Other-Modules: Paths_pkgname}}} but
 then of course Cabal cannot find that module since it is not in the normal
 source directories but in {{{dist/build/autogen}}}. So people have to hack
 around it by adding {{{dist/build/autogen}}} to the {{{Hs-Source-Dirs}}}
 field. Obviously that's rather unsatisfactory.

 Probably the right solution is for Cabal to automatically add that
 directory to the end of the source dir search path.

Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/187>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects

More information about the cabal-devel mailing list