[moving to libraries] On Mon, Jun 13, 2005 at 05:28:43PM -0500, Brian Smith wrote:
* 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.
That's a bug in copy/nstall.
* 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)
The .y and .x shouldn't be part of the module name. It's all much the same as for .hs. The Other-Modules field could be inferred from Main-Is or Exposed-Modules, but it isn't.
* 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."
Cabal puts the generated files in dist/build, along with copies (or cpp's) of the source files.
* 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.
Those error messages ought to be prefixed with the program name (and should go to stderr too).
* 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.
* 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.
Yes, the docs are wrong: a package name is actually one or more alphanumeric words separated by hyphens (though to avoid ambiguity each word should contain at least one letter), while identifiers are as in Haskell.
* 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?
Haskell 98 defines a letter, but it doesn't say how to interpret a text file containing non-ASCII bytes.
* 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.
* 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.
Hmm, the parser can't cope with white space after the relational operator -- another bug.