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

[ross at soi.city.ac.uk]

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