[Hackage] #161: 'sdist' cannot find some modules that 'build' finds ok

[Hackage]

#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