On 23 September 2005 08:45, Johannes Waldmann wrote:
Another way to look at both issues is that if ghc can figure out other modules and packages itself, the user shouldn't be required to specify them in a cabal file. ...
Definitely. Having the list of modules in the .cabal is unnecessary duplication of information (because it's in the sources already). This is bound to get out-of-sync during development - unless you use some kind of Makefile to generate the .cabal file, which defeats the very purpose of Cabal itself.
I know how to do this using GHC, but I'm not sure about other compilers. With GHC, we can generate the dependencies using 'ghc -M' and then parse the generated Makefile (a bit of a long way around, but I can't think of an easier way). Of course we'd avoid splatting an existing Makefile by redirecting the dependencies to a temporary file. How would we do this with nhc98 or Hugs? Perhaps because these systems don't actually need to know the value of other-modules we can get away with it. Comments?
Unrelated question: can someone please share an example that shows how to put user-defined options for haddock in a .cabal?
There's no good way to do it right now. You can override the whole haddock command using hooks, but you'd have to write quite a bit of code to do this. I plan to add something to allow extra Haddock args to be given (the Haddock support is a very bare-bones right now, it should get better). Cheers, Simon