Cabal: Semantics of Hs-Source-Dirs (was Re: Cabal Release Candidate)

[Ross Paterson]

On Sun, Aug 07, 2005 at 11:40:07PM -0500, Brian Smith wrote:
> The documentation implies that, if I include the field:
>      Hs-Source-Dirs: src
> in my Cabal package description, then _ONLY_ src will be considered
> the root source code directory. However, this is not the case. The
> current working directory is always implicitly part of Hs-Source-Dirs,
> at least when running with "runghc" or "runhugs." See the included
> testcase. It looks like this:
>      .cabal file:
>      ....
>      Hs-Source-Dirs: src
>      ...
>      Main-Is: Main.hs
> 
>      files:
>      Hs-Source-Dirs-Test-1.cabal
>      Test1.hs
>      src/Main.hs
> 
> If the documentation was correct, then the package should fail to
> build because "Test1.hs" is in "." instead of in "src/". Yet, with
> both Hugs and GHC, the package builds successfully because they find
> Test1.hs in "."

Note that your package description is faulty in that it doesn't list
the module Test1 -- the last stanza is missing a line

Other-Modules: Test1

As a result building for Hugs produces an incomplete program (the
build phase succeeds because it doesn't do much in this case).
If you include that line, building for Hugs reports an error.

There was a bug with building for GHC, though: it was adding
hs-source-dirs to the default path of ghc --make without resetting
the path first (now fixed).

> Secondly, I have seen references that say that all relative paths in a
> Cabal package are relative to the directory containing the package
> description. This is not true either. Instead, the whole Cabal library
> treats relative paths as relative to the current working directory.
> This is a problem for tools that want to reuse the Cabal API but
> potentially need to change the current working directly throughout
> their execution. For example, if we were to integrate some support for
> Cabal into GHCi, then this would interact badly with the :cd command.

True, it's been assumed that the current directory is the same as the
package root, because that's the way Setup.hs is supposed to be run,
and so far Setup.hs has been the only client for the library.  The
library is ripe for generalization.