Hi Isaac. Now I see why the patch file was empty. And after some head-scratching about your note below, I'm glad the patch was empty. I hadn't noticed the --xxx-args flags for configure, and instead added a new haddock flag. Giving a flag to configure makes a lot more sense. So now I have just a new pair of flags enable-use-packages & disable-use-packages, which control whether haddock gets automatically-generated --use-package flags. My makefile are now performing this sort of incantation: ./setup configure --disable-use-packages --haddock-args="\ --read-interface= http://haskell.org/ghc/docs/latest/html/libraries/base,c:/ghc/ghc-6.6/doc/html/libraries/base/base.haddock\ --read-interface= http://haskell.org/ghc/docs/latest/html/libraries/mtl,c:/ghc/ghc-6.6/doc/html/libraries/mtl/mtl.haddock\ " The only problem is --haddock-args ends up turning my forward slashes into backslashes, so all of the web links are broken. Any advice? - Conal On 1/17/07, Isaac Jones wrote:

Hi Conel. Thanks for this! It sounds like the ideas from your makefile could be used for Hackage for generating nice Haddock :)

There is a general meachanism for adding --foo-args for each Program that cabal knows about; can you use this meachanism to add --foo-arg as well, instead of special-casing for haddock?

If you do that, can you make the help output not suck? Currently it does something like this:

--ar-args=ARGS give the args to ar --haddock-args=ARGS give the args to haddock --ld-args=ARGS give the args to ld --pfesetup-args=ARGS give the args to pfesetup --ranlib-args=ARGS give the args to ranlib --runghc-args=ARGS give the args to runghc --runhugs-args=ARGS give the args to runhugs --tar-args=ARGS give the args to tar

it would be nice to concerve lines with sometthing like this:

--ar-arg=ARG --ar-args=ARGS give the arg or args to ar --haddock-arg=ARG --haddock-args=ARGS give the arg or args to haddock etc

The patch you sent seemed like an empty file to me. Maybe I'm just being nihilistic ;)

peace,

isaac

I love this idea. Having to specify the local interface file is a major defect of my solution. I'd much rather specify just the URL for the external library docs. I'd also be happy to adopt some convention about where to put such docs so they could be determined automatically. Perhaps via indirection where necessary. Then my per-project makefile content would vanish altogether. Ross: I don't understand the last remark below about my requirements differ from HackageDB's. - Conal On 2/19/07, Ross Paterson wrote:

On Fri, Jan 19, 2007 at 05:18:07PM -0800, Conal Elliott wrote:

...

So now I have just a new pair of flags enable-use-packages & disable-use-packages, which control whether haddock gets automatically-generated --use-package flags.

There's a similar (but simpler) problem with generating Haddock documentation for HackageDB. The trouble is that --use-package is half right: it gives the interface file you want, but the wrong URL for cross-references. (And there's no way to override it, because haddock doesn't know which package a --read-interface option relates to.)

For HackageDB, I think the appropriate thing would be for Cabal to use ghc-pkg to get the haddock-interfaces field (instead of asking haddock to ask ghc-pkg for it), but for the user to be able to override the HTML URL at configure time. For HackageDB, a suitable template would be

http://hackage.haskell.org/packages/archive/$pkg/$pkgid.misc/doc/html or

http://hackage.haskell.org/packages/archive/$pkg/latest.misc/doc/html

That wouldn't work for Conal's situation, where the URLs for his own packages point at a different place than the ones distributed with GHC.

_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel

On Mon, Feb 19, 2007 at 05:36:58PM +0000, Ross Paterson wrote:

For HackageDB, I think the appropriate thing would be for Cabal to use ghc-pkg to get the haddock-interfaces field (instead of asking haddock to ask ghc-pkg for it), but for the user to be able to override the HTML URL at configure time.

Another reason for Cabal to call ghc-pkg instead of asking haddock to is to ensure that it is the same ghc-pkg that we specified to Cabal, rather than the one haddock plucks out of the environment.