#161: 'sdist' cannot find some modules that 'build' finds ok ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: closed Priority: high | Milestone: Cabal-1.4 Component: Cabal library | Version: 1.2.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.6 | Platform: Linux ----------------------------+----------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => fixed Comment: Ok, discovered the problem and why the behavior was inconsistent. Turns out it __should__ fail in the `build` step too. The `sdist` was behaving properly and building (or rather pre-processing) should not have found that file. So it turns out that {{{ hs-source-dirs: tests . }}} in the executable section is not just a workaround but the correct thing to do. Let's look at the .cabal file again: {{{ ... snip ... build-depends: base, bytestring, HUnit, network exposed-modules: Network.Socket.ByteString extensions: CPP, ForeignFunctionInterface executable: tests main-is: UnitTests.hs hs-source-dirs: tests other-modules: Network.Socket.ByteString extensions: CPP, ForeignFunctionInterface }}} And we have these files: {{{ Network/SocketByteString.cpphs tests/UnitTests.hs }}} The meaning of `hs-source-dirs` is to look in just those directories for source files. If it is not specified then it defaults to `.` however note that `.` is __not__ added to the list if `hs-source-dirs` is specified explicitly. So it's actually quite right that `Network/SocketByteString.cpphs` is not found for the executable which specifies `hs-source-dirs: tests`. Indeed if we change the file to `Network/SocketByteString.hs` then we'll see that ghc cannot find the file, because we're passing `-i -itests` which means to clear the search path completely and then add `tests` to the search path. So why does it get found when we use a `.cpphs` file rather than a `.hs` file? Well that's the bug. The pre-processing code for executables was combining the search path for the executable with the search path for the library: {{{ nub $ (hsSourceDirs bi) ++ (maybe [] (hsSourceDirs . libBuildInfo) (library pkg_descr))) }}} So the `.cpphs` source file got found and the pre-processed output then goes into a directory that we do tell ghc to look in and that's why it was being found. The consistent thing to do here is to use just `(hsSourceDirs bi)`. (`bi` here refers to the build info for the executable in question). So I think that fixes the inconsistency by bringing pre-processing into line with everything else. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/161#comment:5 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects