Ross,
Thank you for your quick reply. I have some responses below.
On 6/13/05, ross@soi.city.ac.uk
[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