patch applied (ghc): Merge Haddock comment support from
ghc.haddock -- big patch
duncan.coutts at worc.ox.ac.uk
Sun Oct 8 10:37:16 EDT 2006
On Sun, 2006-10-08 at 16:20 +0200, Sven Panne wrote:
> Am Sonntag, 8. Oktober 2006 15:07 schrieb Duncan Coutts:
> > [...] That would be very much appreciated. If you feel like making release
> > candidate tarballs for them all then the Gentoo Haskell packaging people
> > will endeavour to test them. [...]
> I don't know about the latest and greatest release plans for the tools, so
> I'll leave this to SimonM.
Oh, sorry. I misread what you said as offering to do the releases. :-)
> > One gotcha to look out for with haddock is that the tarball needs to
> > contain the pre-processed .hs files produced by happy and alex. At the
> > moment Cabal doesn't automate that at all so it needs to be done
> > manually. Otherwise we end up with haddock needing alex & happy. We
> > noticed this problem in the haddock-0.8_rc1 release.
> Is this really needed? To build all tools and GHC, one only needs a working
> bootstrapping GHC, then Happy => Alex => Haddock => GHC can be built in this
> order. Or am I missing something?
You're right, it's not essential. But it is convenient, especially for
users of source based distributions. The average user is very likely to
need haddock since it's used by every cabalised library (if the user
chooses to build docs), but they are rather unlikely to need alex and
> > This also reminds me: a week or so ago when I was visiting Chalmers, we
> > had a hacking session where we added new ByteString '%wrapper's to alex.
> > I'll try to tidy up the patches and send them in. I'll try and get some
> > performance numbers too.
> That would be nice, although I never had any performance problems with Alex.
> But performance is always good... ;-)
Aye. GHC already uses alex to lex directly out of a big slurped buffer.
We'd like to make that available and easy for everyone, and indeed more
flexible as we can lex from a lazy ByteString so we don't need the whole
file to be in memory before lexing starts.
More information about the Cvs-ghc