I succeeded in getting my project to build under Cabal. As I converted my makefile to Cabal, I took some notes about things that I found unintuitive, so that the documentation can be improved for future new users. There are some questions mixed in as well. I am using GHC, Cabal, Happy, Alex, and Haddock, all from the CVS head, all built with GHC 6.2.2, all executing under MSYS 1.0's bash 2.04.0(1) on Windows XP Pro SP2. * If I use "Executable: check-ocl2," then under Windows the executable's name really becomes "check-ocl2.exe." This is desireable behavior. But, this causes "Setup.hs copy" and "Setup.hs install" to fail because it tries to copy a file named "check-ocl2" (without the ".exe"), which obviously doesn't exist. How can I get Cabal to generate "check-ocl2.exe" on Windows and "check-ocl2" on all other platforms, and have the "copy" and "install" commands work, without using autoconf? * What is the easiest way to create a "Setup.hs all" command, analogous to "make all" that simply executes "configure." "build," "haddock," and "test" in sequence, stopping on the first failed step? * The tutorial documentation should explain how to use tools like alex and happy. As far as I could tell, the way to do this is to add "Other-Modules: Module.Name.Of.Parser.y Module.Name.Of.Lexer.x" to each executable/library stanza. But, I am not sure why this is necessary, as it seems like it should be able to find them automatically (i.e. without having to list them in the Other-Modules: field) * Is there some way to tell Cabal to generate all intermediate files into a directory that is different than the source directory? I usually keep all my sources in a "src" directory, and then generate 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." * If I run "runghc ./Setup.hs" I get this message: No command given (try --help). This is confusing because it isn't clear that it is a cabal error message and not a runghc error message. That is, it isn't clear whether to run "runghc --help" or "runghc Setup.hs --help," and both commands are valid. The message should be improved, or "--help" should be the default command. * Chapter 2 needs to be updated to replace "Hs-Source-Dir" with "Hs-Source-Dirs," since Hs-Source-Dir is deprecated. * It is unintuitive that the examples in chapter 2 use mixed case (e.g. "Hs-Source-Dir") while the program issues error messages using lowercase only ("hs-source-dir"). * Chapter 2 of the documentation states that identifiers can contain underscores. However, Cabal gives "*** Exception: Line 1: Parse of field 'name' failed" if I use "Name: ocl2_haskell" whereas "Name: ocl2haskell" works fine. * Chapter 2 of the documentation states that identifiers must start with a letter. However, "Name: 2" is parsed without complaint. * Chapter 2 of the documentation states that idenfiers must start with a letter. However, "letter" is not defined. Presumably the intention is to restrict identifiers to English letters only? * 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? For example, my unit tests require HUnit, but nothing else does. Should I put my unit tests into a seperate package? * The error message for putting "Build-depends: base" in an "Executable: " stanza is: "*** Exception: Line 10: Unknown field 'build-depends' but I think it would be better to say *** Exception: Line 10: field 'build-depends' does not apply to executables or even better: *** Exception: Line 10: field 'build-depends' applies only to the main stanza (and similarly for other fields, e.g. "field 'main-is" applies only to executables") * Chapter 2 of the documentation states that I should be able to use syntax like "foo > 1.2" in Build-depends, but I could not get "HUnit > 1.1" or "HUnit >= 1.1" to work; they fail with parser errors. Regards, Brian