(CC'ing libraries) (snip)
I'd certainly welcome Cabal support for other haddock features as well (--source, --read-interface). I am not sure where to put all these arguments in the .cabal file.
Cabal doesn't support these yet, though. Maybe in the future.
Dear Isaac,
for the next release, I think *every* external program used by Cabal should get a xyz-options (free form) tag to give additional options. We already have them for linker, c-compiler, and hs-compiler, but not yet for preprocessors and doc generators (haddock). This is very easy to implement, does no harm at all, and greatly increases cabal's flexibility as a build tool. (BTW, I can send you a darcs patch if you are too busy at the moment.)
And in the other thread you said:
I made the necessary changes for hsc2hs-options in a few minutes
You added hsc2hs-options to the package description? Cool. I'm happy to get a patch to add options fields to all the preprocessors and haddock and anything else we may have missed. There are basically 3 ways that people can customize their packages: - the .cabal file - the Setup script with UserHooks - flags to configure I was originally thinking of these extra flags as something to pass to configure, but actually putting them in the description file would be more consistent with what we have already... One trick, though, is to make sure that the parser test cases for cabal still run when you make the changes. It's all too common for someone to add a field and break the parser or pretty printer. The important thing is that when you parse it, pretty print it, and parse it again it comes out the same. Check out tests/ModuleTest.hs
(BTW, I can send you a darcs patch if you are too busy at the moment.)
I like patches whether I'm busy or not. It'll definitely get done faster ;) BTW, I'm tracking this feature request in the Debian bug tracking system for the haskell-cabal package. peace, isaac
On Friday 22 April 2005 17:09, Isaac Jones wrote:
I'd certainly welcome Cabal support for other haddock features as well (--source, --read-interface). I am not sure where to put all these arguments in the .cabal file.
Cabal doesn't support these yet, though. Maybe in the future.
Dear Isaac,
for the next release, I think *every* external program used by Cabal should get a xyz-options (free form) tag to give additional options. We already have them for linker, c-compiler, and hs-compiler, but not yet for preprocessors and doc generators (haddock). This is very easy to implement, does no harm at all, and greatly increases cabal's flexibility as a build tool. (BTW, I can send you a darcs patch if you are too busy at the moment.)
And in the other thread you said:
I made the necessary changes for hsc2hs-options in a few minutes
You added hsc2hs-options to the package description? Cool. I'm happy to get a patch to add options fields to all the preprocessors and haddock and anything else we may have missed.
I'll give it a try.
There are basically 3 ways that people can customize their packages: - the .cabal file - the Setup script with UserHooks - flags to configure
I was originally thinking of these extra flags as something to pass to configure, but actually putting them in the description file would be more consistent with what we have already...
'Flags to configure' is -- at least in my case -- not the correct solution, because only the package author knows what extra options are necessary. The user shouldn't need to bother with it. I haven't looked very deeply into UserHooks yet, but I think passing extra options is common enough to justify dot-cabal tags.
One trick, though, is to make sure that the parser test cases for cabal still run when you make the changes. It's all too common for someone to add a field and break the parser or pretty printer. The important thing is that when you parse it, pretty print it, and parse it again it comes out the same. Check out tests/ModuleTest.hs
Ok, I will add test cases and make sure all tests pass before sending anything. Cheers, Ben
participants (2)
-
Benjamin Franksen -
Isaac Jones