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