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

[Brian Smith]

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 "."

Yet, let's say I switch the locations of Test1.hs and Main.hs:
    Hs-Source-Dirs: src
    Main-Is: Main.hs
    
    files:
    Hs-Source-Dirs-Test-2.cabal
    Main.hs
    src/Test.hs
    
I would guess, from the results of Test1, that Test2 should
successfully build. Yet, it fails: with "Setup.hs: Main.hs doesn't
exists" [sic].

>From the results of these two tests, we can conclude that sometimes
"." is part of the module search path, and sometimes it isn't. This is
bad. Either "." should be always be implicitly part of the search path
(better), or it should be implicitly part of the search path _only
when no Hs-Source-Dirs field is present_ (best).

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.

- Brian



On 7/14/05, Isaac Jones <ijones at syntaxpolice.org> wrote:
> I've updated the web page to have 1.0 (as Malcolm requested), and
> added 1.1.1, which is a "release candidate" for 1.2.  Please forgive
> me for going insane with the version numbers.
> 
> I'd appreciate it if early adopter types try out 1.1.1.  In
> particular, check out the README wrt installing alongside-of or
> instead-of 1.0 with ghc 6.4.
> 
> BTW, if anyone loves to manage releases and would like to relieve me
> of this duty so I can spend my time fixing bugs and adding features,
> just let me know ;)
> 
> peace,
> 
>   isaac
> 
> 
> ---------------------------------------------------------------
>                       The Haskell Cabal
> The Common Architecture for Building Applications and Libraries.
> http://www.haskell.org/cabal
> 
> IMPORTANT INFORMATION:
> 
> See both the README file and the changelog for important interface
> changes and installation instructions.
> 
> DOWNLOAD:
> 
> The Haskell Cabal has reached version 1.1.1.  This pre-release has a
> number of new features including a hook for testing, support for
> profiling, and support for _stub files, as well as several bug fixes.
> 
> Download the Cabal here (source and debian versions available):
> http://www.haskell.org/cabal/download.html
> 
> BUGS:
> 
> Please report bugs and wish-list items to libraries at haskell.org and
> Isaac Jones: ijones at syntaxpolice.org.
> 
> ABOUT:
> 
> The Haskell Cabal is meant to be a part of a larger infrastructure for
> distributing, organizing, and cataloging Haskell Libraries and
> Tools. It is an effort to provide a framework for developers to more
> effectively contribute their software to the Haskell community.
> 
> Specifically, the Cabal describes what a Haskell package is, how these
> packages interact with the language, and what Haskell implementations
> must to do to support packages. The Cabal also specifies some
> infrastructure (code) that makes it easy for tool authors to build and
> distribute conforming packages.
> 
> The Cabal is only one contribution to the larger goal. In particular,
> the Cabal says nothing about more global issues such as how authors
> decide where in the module name space their library should live; how
> users can find a package they want; how orphan packages find new
> owners; and so on.
> 
> NOTES:
> 
> You cannot currently execute most setup scripts with "./Setup.lhs"
> since most systems do not have a runHaskell executable installed.  You
> can compile it with ghc thusly: "ghc -package Cabal Setup.lhs -o
> setup" and then use the "setup" executable after that.
> 
> This release is meant to provide the community with concrete
> information about how the interfaces are shaping up.  This release
> does NOT fix the interfaces, we can't promise not to break anything
> that relies on these interfaces.  We hope that Haskell authors will
> try to package their software using these tools, and let us know where
> they fall short.
> 
> MORE INFORMATION:
> 
> Please see the web site for the source code, interfaces, and
> especially the proposal, which will serve as documentation for this
> release:
> 
> http://www.haskell.org/cabal/
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hs-source-dirs-test-1.tar.gz
Type: application/x-gzip
Size: 534 bytes
Desc: not available
Url : http://www.haskell.org//pipermail/libraries/attachments/20050807/7070585b/hs-source-dirs-test-1.tar.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hs-source-dirs-test-2.tar.gz
Type: application/x-gzip
Size: 861 bytes
Desc: not available
Url : http://www.haskell.org//pipermail/libraries/attachments/20050807/7070585b/hs-source-dirs-test-2.tar.bin