Gearing up (again) for the next release: 2014.2.0.0
Mateusz Kowalczyk
fuuzetsu at fuuzetsu.co.uk
Thu Apr 3 18:42:20 UTC 2014
On 03/04/14 13:48, Edward Kmett wrote:
> haddock interoperates rather extremely closely with the ghc-api.
>
> Pulling it out would make something that already seems to go a bit out of
> sync with each release that much harder to keep in sync.
>
> It is also used to build the documentation for all the packages that ship
> with ghc out of the box. Pulled out I don't see a sane way to generate
> those docs.
>
> -Edward
>
>
>
>
> On Thu, Apr 3, 2014 at 8:32 AM, harry <voldermort at hotmail.com> wrote:
>
>> Jens Petersen wrote
>>>> *Haddock* - is there any reason not to use the version built and
>>>> distributed with GHC 7.8?
>>>
>>> from the package perspective also, +1 for continuing to use the haddock
>> in
>>> ghc.
>>
>> Perhaps Haddock shouldn't be included with GHC either, now that we have HP
>> for the batteries included distribution?
>>
>>
>>
>> --
>> View this message in context:
>> http://haskell.1045720.n5.nabble.com/Gearing-up-again-for-the-next-release-2014-2-0-0-tp5746660p5746881.html
>> Sent from the Haskell - Libraries mailing list archive at Nabble.com.
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
Another downside is that it's up to Haddock maintainers to now very
closely follow GHC changes rather than GHC HQ jumping in and fixing it
up when they change the API.
Ideally, I'd love to be able to not work as closely with GHC, it's quite
a burden to have to keep up-to-date GHC versions and possible break GHC
builds when we mess up but at the moment that's how it is.
--
Mateusz K.
More information about the Libraries
mailing list