Advance notice that I'd like to make Cabal depend on parsec
carter.schonwald at gmail.com
Mon Mar 18 02:08:07 CET 2013
is there any downside using a human readable Read/Show instance for the ghc
package database serialization piece?
adding parsec to the baked into ghc core would have pretty strong
implications on which versions of other packages (where applicable) can be
built with ghc...
*Zooming out a teeny bit*... wasn't there some recent discussion on making
it easier to have ghc coherently cope with multiple versions of a library
being installed? I feel like this parsec inclusion would be a lot *less*
contentious once thats been done, because then the ghc usage of the parsec
library could be private / hidden from end users (possibly?)
On Sun, Mar 17, 2013 at 4:20 PM, Henning Thielemann <
lemming at henning-thielemann.de> wrote:
> On Sun, 17 Mar 2013, Ian Lynagh wrote:
> On Sun, Mar 17, 2013 at 09:04:58PM +0100, Henning Thielemann wrote:
>>> On Sun, 17 Mar 2013, Ian Lynagh wrote:
>>> I think it would be feasible to stop GHC itself from using the human
>>>> readable format. The only place I can think of it being used is in the
>>>> package database, but we could use either Read/Show for that, or just
>>>> exclusively use the binary format.
>>> I already needed the human readable format in order to check what
>>> information a custom configure file generated.
>> You can use "ghc-pkg describe p" for that.
>> I don't think you should ever need the human readable format unless you
>> need to alter the package database by hand.
> I think I also altered these package descriptions in order to check what
> the correct content should be.
> ghc-devs mailing list
> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs