Re: [Haskell-cafe] Notes and questions from a first-time Cabal user.
[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.
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
Hi Brian, For the next major release of Cabal, the plan is to deprecate packages with library and multiple executables. Each library/executable will have its own .cabal file. In this case it isn't required to split the build-depends field. Cheers, Krasimir
* 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.
participants (3)
-
Brian Smith -
Krasimir Angelov -
ross＠soi.city.ac.uk