[Haskell-cafe] Notes and questions from a first-time Cabal user.

[Brian Smith]

Ross,

Thank you for your quick reply. I have some responses below.

On 6/13/05, ross at soi.city.ac.uk <ross at soi.city.ac.uk> wrote:
> [moving to libraries]
> > * Is there some way to tell Cabal to generate all 
> > all .hi, .o, and .hs files from Happy and Alex into a "build"
> > directory alongside it. This way, my "src" directory only contains
> > stuff that belongs in my version control repository, and "make clean"
> > was simply "rm -Rf build."
> 
> Cabal puts the generated files in dist/build, along with copies (or
> cpp's) of the source files.

It still puts Happy- and Alex- generated .hs files into src/ though. I
want nothing to be written into the src/ directory at all.

> > * Chapter 2 needs to be updated to replace "Hs-Source-Dir" with
> > "Hs-Source-Dirs," since Hs-Source-Dir is deprecated.
> 
> The CVS version of the docs are updated; the web version describes
> GHC 6.4.

I am using the CVS version of the documentation. I looked again and
you are right that the prose parts indeed have hs-source-dirs, but the
examples in chapter 2 still use Hs-Source-Dir.

> > * I originally put my "Build-depends: base" in an "Executable:"
> > stanza. This seems reasonable because presumably different executables
> > (and libraries) could have different dependencies, and it is
> > advantageous to keep track of dependencies on a fine-grained basis.
> > Yet, Cabal requires the Build-depends to be in the main stanza. Why is
> > this? Couldn't Cabal combine all the Build-Depends it finds into the
> > one that it puts into the final package specification?
> 
> It is confusing that the first stanza contains both fields describing the
> whole package and fields describing a library.  But Build-depends is a
> package-level thing (it's not in 2.1.2) because Cabal takes the package
> as the unit of distribution, building, etc.  If you want to build this
> pachage, these are the other packages you need to have installed first.
> There has been some talk of a coarser level of structure in the indefinite
> future.

I understand that. But, your point and my point are not in
disagreement. I will try to illustrate what I am saying with some
examples:

(1) Let's say that Build-Depends can be put into executable and
library stanzas. So, we might have:
Name: AandB
...
Library: a
Build-Depends: PackageA, PackageB >= 1.0
...
Executable: b
Build-Dpends: PackageB >= 1.1, PackageC
...

Now, when Cabal generates the package specification for package AandB,
the resulting package spec. would list dependencies PackageA, PackageB
>= 1.1, and PackageC. But, it would also ensure that
    (a) Library "a" does NOT depend on PackageC, and it only depends on 
         features from PackageB that are in version 1.0
    (b) Executable "b" does not depend on PackageA

This gives the programmer some piece of mind that he has not
intruduced any dependencies accidently.

(2) I want to have the "build" command succeed on a system without
HUnit, and the "test" command to fail if HUnit is missing. I could
split the unit tests into a seperate package but that seems to negate
the purpose of having a "test" command in Cabal in the first place.

Also, a new question: How do I state in my .cabal file that my module
requires Happy > 1.15 and Alex > 2.0?

Thanks,
Brian