[Haskell-cafe] GHC API + Cabal API + Cabal version checks: is there a way out?

JP Moresmau jpmoresmau at gmail.com
Fri Sep 6 17:04:08 CEST 2013


Oh, I'm happy to help as well if somebody is needed to do the change, since
I have much to win in the future if EclipseFP can take advantage of a new
version of Cabal without having to wait for a new GHC. The split in two
libraries that Duncan mentions seems the best approach to me, having
InstalledPackageInfo and related classes + parsers + pretty printers
available as one reasonably stable library, while having another one for
the real Cabal functionality...

JP


On Fri, Sep 6, 2013 at 5:00 PM, Yuri de Wit <ydewit at gmail.com> wrote:

> Alejandro,
>
> that is correct, as I see it. Duncan has very good points there but it
> seems to me that we need a concrete proposal so we can propose solutions to
> the problem. The fact is that the current situation is a middle of the
> ground that doesn't help Cabal nor Ghc.
>
>
>
>
> On Fri, Sep 6, 2013 at 10:54 AM, Alejandro Serrano Mena <trupill at gmail.com
> > wrote:
>
>> I'm willing to help in the process, if some directions were given to me
>> on how to tackle this problem.
>>
>> In any case, for me is seems fine to have a dependency from cabal to ghc,
>> the only problem is the converse: ghc depending on cabal. Is this right?
>>
>>
>> 2013/9/6 Herbert Valerio Riedel <hvr at gnu.org>
>>
>>> On 2013-09-06 at 15:13:58 +0200, Yuri de Wit wrote:
>>> > I spent some time looking into the touch points between ghc and cabal
>>> in
>>> > the past, and the first oddity i saw was a direct dependency from ghc
>>> to
>>> > the cabal sources. After taking a closer look it seems that ghc shares
>>> some
>>> > common, low level modules with cabal that didnt seem to justify the
>>> whole
>>> > dependency.
>>> >
>>> > The right solution, imho, is to review these dependencies and move the
>>> low
>>> > level ones out into a separate package that is shared by both ghc and
>>> cabal
>>> > and that will rarely change. The direct side effect of this is that ghc
>>> > would not be tied directly to a specific cabal version and you would
>>> > not have to deal with this issue.
>>>
>>> [...]
>>>
>>> fyi, a similiar/related discussion took place few months ago on ghc-devs:
>>>
>>>  http://www.haskell.org/pipermail/ghc-devs/2013-March/000800.html
>>>
>>> hth,
>>>   hvr
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>


-- 
JP Moresmau
http://jpmoresmau.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130906/305653b1/attachment.htm>


More information about the Haskell-Cafe mailing list