GHC API + Cabal API + Cabal version checks: is there a way out?

older
GHC API question: Getting access...

JP Moresmau

6 Sep 2013 6 Sep '13

7:51 a.m.

Hello all, I have an issue that has been nagging me for a while, and I'd like to make sure I haven't missed a solution to it. I'm the maintainer for the buildwrapper package. This package has dependencies on the Cabal and GHC libraries, and also uses the cabal-install executable. For example it will run cabal configure by invoking the executable, then it will load the LocalBuildInfo via the Cabal API, and extract the relevant information to start a GHC session with the proper flags, etc. Now yesterday some great news were announced, a new version of Cabal! However, I can't use it. I can of course install the Cabal library and rebuild the cabal executable but - buildwrapper will only use the version of the Cabal library that was bundled with GHC, since the GHC library has a dependency on that version of Cabal - so the library access will be using Cabal 1.16, but the executable will be 1.18 - and the library checks when reading the setup-config file that the Cabal versions match. Hence, running configure with 1.18 create build information I can't read back in 1.16. So I'm stuck. People can easily install cabal 1.18 and build their projects with it, but I can't use it in conjunction with buildwrapper. Some solutions I've considered - do not use the Cabal API and write my own code to read the local build info, and to replace all the Cabal library code I use - do not use the cabal-install executable but do everything by the API Both solutions reek of madness, and involve rewriting code that others have already written, and a maintenance nightmare with each Cabal release. So, do I have to wait a new release of GHC/Haskell Platform or is there a better solution? I suspect ghc-mod and other similar packages have the same issues. Thanks for any help! -- JP Moresmau http://jpmoresmau.blogspot.com/

Attachments:

attachment.html (text/html — 2.1 KB)

Show replies by date

Yuri de Wit

6 Sep 6 Sep

9:13 a.m.

New subject: GHC API + Cabal API + Cabal version checks: is there a way out?

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. Re: specific workaround i am not sure. On Friday, September 6, 2013, JP Moresmau wrote:

...

Hello all,

I have an issue that has been nagging me for a while, and I'd like to make sure I haven't missed a solution to it. I'm the maintainer for the buildwrapper package. This package has dependencies on the Cabal and GHC libraries, and also uses the cabal-install executable. For example it will run cabal configure by invoking the executable, then it will load the LocalBuildInfo via the Cabal API, and extract the relevant information to start a GHC session with the proper flags, etc. Now yesterday some great news were announced, a new version of Cabal! However, I can't use it. I can of course install the Cabal library and rebuild the cabal executable but - buildwrapper will only use the version of the Cabal library that was bundled with GHC, since the GHC library has a dependency on that version of Cabal - so the library access will be using Cabal 1.16, but the executable will be 1.18 - and the library checks when reading the setup-config file that the Cabal versions match. Hence, running configure with 1.18 create build information I can't read back in 1.16.

So I'm stuck. People can easily install cabal 1.18 and build their projects with it, but I can't use it in conjunction with buildwrapper. Some solutions I've considered - do not use the Cabal API and write my own code to read the local build info, and to replace all the Cabal library code I use - do not use the cabal-install executable but do everything by the API

Both solutions reek of madness, and involve rewriting code that others have already written, and a maintenance nightmare with each Cabal release.

So, do I have to wait a new release of GHC/Haskell Platform or is there a better solution? I suspect ghc-mod and other similar packages have the same issues.

Thanks for any help!

-- JP Moresmau http://jpmoresmau.blogspot.com/

Niklas Hambüchen

9:42 a.m.

New subject: GHC API + Cabal API + Cabal version checks: is there a way out?

On Fri 06 Sep 2013 22:13:58 JST, Yuri de Wit wrote:

...

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.

This sounds very right to me. There should be something that describes what a GHC package database is, as minimally as possible (perhaps even only the data types). In the end, ghc is the defining side here - cabal is only a tool that builds on top of these definitions. Then ghc could finally be decoupled from Cabal.

Roman Cheplyaka

9:52 a.m.

New subject: GHC API + Cabal API + Cabal version checks: is there a way out?

The right solution for Cabal would be not to know anything about the GHC's database format at all. GHC and cabal communicate via a command line interface (`ghc-pkg dump` in our direction; `ghc-pkg update` in the other). So it would suffice to have a library which implements parsing and printing of the package description, and have that library shared between GHC and Cabal. (Which I think is more or less what you guys are suggesting, only I'd like to point out that we should be focusing on the protocol instead of the database format. The latter should be opaque.) Roman * Niklas Hambüchen [2013-09-06 22:42:28+0900]

...

On Fri 06 Sep 2013 22:13:58 JST, Yuri de Wit wrote:

...
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.

This sounds very right to me.

There should be something that describes what a GHC package database is, as minimally as possible (perhaps even only the data types).

In the end, ghc is the defining side here - cabal is only a tool that builds on top of these definitions.

Then ghc could finally be decoupled from Cabal.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Niklas Hambüchen

10:17 a.m.

New subject: GHC API + Cabal API + Cabal version checks: is there a way out?

On Fri 06 Sep 2013 22:52:40 JST, Roman Cheplyaka wrote:

...

The right solution for Cabal would be not to know anything about the GHC's database format at all.

GHC and cabal communicate via a command line interface (`ghc-pkg dump` in our direction; `ghc-pkg update` in the other). So it would suffice to have a library which implements parsing and printing of the package description, and have that library shared between GHC and Cabal.

You are right. This is better. GHC's dependency on cabal seems to actually be quite minimal! I did a quick grep: % grep -rI "import Distribution" --include "*.hs" --include "*.lhs*" . | grep -v "libraries/" | grep -v Setup.hs | grep -v Setup.lhs | grep -v utils/haddock ./utils/ghc-cabal/Main.hs:import Distribution.PackageDescription ./utils/ghc-cabal/Main.hs:import Distribution.PackageDescription.Check hiding (doesFileExist) ./utils/ghc-cabal/Main.hs:import Distribution.PackageDescription.Configuration ./utils/ghc-cabal/Main.hs:import Distribution.PackageDescription.Parse ./utils/ghc-cabal/Main.hs:import Distribution.System ./utils/ghc-cabal/Main.hs:import Distribution.Simple ./utils/ghc-cabal/Main.hs:import Distribution.Simple.Configure ./utils/ghc-cabal/Main.hs:import Distribution.Simple.LocalBuildInfo ./utils/ghc-cabal/Main.hs:import Distribution.Simple.Program ./utils/ghc-cabal/Main.hs:import Distribution.Simple.Program.HcPkg ./utils/ghc-cabal/Main.hs:import Distribution.Simple.Utils (defaultPackageDesc, writeFileAtomic, toUTF8) ./utils/ghc-cabal/Main.hs:import Distribution.Simple.Build (writeAutogenFiles) ./utils/ghc-cabal/Main.hs:import Distribution.Simple.Register ./utils/ghc-cabal/Main.hs:import Distribution.Text ./utils/ghc-cabal/Main.hs:import Distribution.Verbosity ./utils/ghctags/Main.hs:import Distribution.Simple.GHC ( componentGhcOptions ) ./utils/ghctags/Main.hs:import Distribution.Simple.Configure ( getPersistBuildConfig ) ./utils/ghctags/Main.hs:import Distribution.Simple.Compiler ( compilerVersion ) ./utils/ghctags/Main.hs:import Distribution.Simple.Program.GHC ( renderGhcOptions ) ./utils/ghctags/Main.hs:import Distribution.PackageDescription ( library, libBuildInfo ) ./utils/ghctags/Main.hs:import Distribution.Simple.LocalBuildInfo ./utils/ghc-pkg/Main.hs:import Distribution.InstalledPackageInfo.Binary() ./utils/ghc-pkg/Main.hs:import Distribution.ModuleName hiding (main) ./utils/ghc-pkg/Main.hs:import Distribution.InstalledPackageInfo ./utils/ghc-pkg/Main.hs:import Distribution.Compat.ReadP ./utils/ghc-pkg/Main.hs:import Distribution.ParseUtils ./utils/ghc-pkg/Main.hs:import Distribution.Package hiding (depends) ./utils/ghc-pkg/Main.hs:import Distribution.Text ./utils/ghc-pkg/Main.hs:import Distribution.Version ./compiler/ghci/Linker.lhs:import Distribution.Package hiding (depends, PackageId) ./compiler/main/Packages.lhs:import Distribution.InstalledPackageInfo ./compiler/main/Packages.lhs:import Distribution.InstalledPackageInfo.Binary ./compiler/main/Packages.lhs:import Distribution.Package hiding (PackageId,depends) ./compiler/main/PackageConfig.hs:import Distribution.InstalledPackageInfo ./compiler/main/PackageConfig.hs:import Distribution.ModuleName ./compiler/main/PackageConfig.hs:import Distribution.Package hiding (PackageId) ./compiler/main/PackageConfig.hs:import Distribution.Text ./compiler/main/PackageConfig.hs:import Distribution.Version ./compiler/main/Finder.lhs:import Distribution.Text ./compiler/main/Finder.lhs:import Distribution.Package hiding (PackageId) As you can see, there are only 4 files in ghc itself that depend on Cabal: ./compiler/ghci/Linker.lhs ./compiler/main/Packages.lhs ./compiler/main/PackageConfig.hs ./compiler/main/Finder.lhs (plus 1 file for ghc-pkg: ./utils/ghc-pkg/Main.hs) The ones in GHC core seem to rely only on quite basic data types. From this, I would boldly claim that people have spent more time making the GHC build system work with this Cabal dependency than it would take stripping it off! (In fact, I would try to do this right now if the GHC build system wouldn't take so long to compile even the smallest changes ...)

Yuri de Wit

10:22 a.m.

New subject: GHC API + Cabal API + Cabal version checks: is there a way out?

That's right, Roman, not knowing anything about it would be even better! Here is the same dependency info in a different format. I also noticed that cabal has a more complete implementation of Version. Couldn't this also move/merged with base (I think there is already a Version module in base or something like that). On Fri, Sep 6, 2013 at 10:17 AM, Niklas Hambüchen wrote:

...

On Fri 06 Sep 2013 22:52:40 JST, Roman Cheplyaka wrote:

...
The right solution for Cabal would be not to know anything about the GHC's database format at all.

GHC and cabal communicate via a command line interface (`ghc-pkg dump` in our direction; `ghc-pkg update` in the other). So it would suffice to have a library which implements parsing and printing of the package description, and have that library shared between GHC and Cabal.

You are right. This is better.

GHC's dependency on cabal seems to actually be quite minimal!

I did a quick grep:

% grep -rI "import Distribution" --include "*.hs" --include "*.lhs*" . | grep -v "libraries/" | grep -v Setup.hs | grep -v Setup.lhs | grep -v utils/haddock ./utils/ghc-cabal/Main.hs:import Distribution.PackageDescription ./utils/ghc-cabal/Main.hs:import Distribution.PackageDescription.Check hiding (doesFileExist) ./utils/ghc-cabal/Main.hs:import Distribution.PackageDescription.Configuration ./utils/ghc-cabal/Main.hs:import Distribution.PackageDescription.Parse ./utils/ghc-cabal/Main.hs:import Distribution.System ./utils/ghc-cabal/Main.hs:import Distribution.Simple ./utils/ghc-cabal/Main.hs:import Distribution.Simple.Configure ./utils/ghc-cabal/Main.hs:import Distribution.Simple.LocalBuildInfo ./utils/ghc-cabal/Main.hs:import Distribution.Simple.Program ./utils/ghc-cabal/Main.hs:import Distribution.Simple.Program.HcPkg ./utils/ghc-cabal/Main.hs:import Distribution.Simple.Utils (defaultPackageDesc, writeFileAtomic, toUTF8) ./utils/ghc-cabal/Main.hs:import Distribution.Simple.Build (writeAutogenFiles) ./utils/ghc-cabal/Main.hs:import Distribution.Simple.Register ./utils/ghc-cabal/Main.hs:import Distribution.Text ./utils/ghc-cabal/Main.hs:import Distribution.Verbosity ./utils/ghctags/Main.hs:import Distribution.Simple.GHC ( componentGhcOptions ) ./utils/ghctags/Main.hs:import Distribution.Simple.Configure ( getPersistBuildConfig ) ./utils/ghctags/Main.hs:import Distribution.Simple.Compiler ( compilerVersion ) ./utils/ghctags/Main.hs:import Distribution.Simple.Program.GHC ( renderGhcOptions ) ./utils/ghctags/Main.hs:import Distribution.PackageDescription ( library, libBuildInfo ) ./utils/ghctags/Main.hs:import Distribution.Simple.LocalBuildInfo ./utils/ghc-pkg/Main.hs:import Distribution.InstalledPackageInfo.Binary() ./utils/ghc-pkg/Main.hs:import Distribution.ModuleName hiding (main) ./utils/ghc-pkg/Main.hs:import Distribution.InstalledPackageInfo ./utils/ghc-pkg/Main.hs:import Distribution.Compat.ReadP ./utils/ghc-pkg/Main.hs:import Distribution.ParseUtils ./utils/ghc-pkg/Main.hs:import Distribution.Package hiding (depends) ./utils/ghc-pkg/Main.hs:import Distribution.Text ./utils/ghc-pkg/Main.hs:import Distribution.Version ./compiler/ghci/Linker.lhs:import Distribution.Package hiding (depends, PackageId) ./compiler/main/Packages.lhs:import Distribution.InstalledPackageInfo ./compiler/main/Packages.lhs:import Distribution.InstalledPackageInfo.Binary ./compiler/main/Packages.lhs:import Distribution.Package hiding (PackageId,depends) ./compiler/main/PackageConfig.hs:import Distribution.InstalledPackageInfo ./compiler/main/PackageConfig.hs:import Distribution.ModuleName ./compiler/main/PackageConfig.hs:import Distribution.Package hiding (PackageId) ./compiler/main/PackageConfig.hs:import Distribution.Text ./compiler/main/PackageConfig.hs:import Distribution.Version ./compiler/main/Finder.lhs:import Distribution.Text ./compiler/main/Finder.lhs:import Distribution.Package hiding (PackageId)

As you can see, there are only 4 files in ghc itself that depend on Cabal:

./compiler/ghci/Linker.lhs ./compiler/main/Packages.lhs ./compiler/main/PackageConfig.hs ./compiler/main/Finder.lhs

(plus 1 file for ghc-pkg: ./utils/ghc-pkg/Main.hs)

The ones in GHC core seem to rely only on quite basic data types.

From this, I would boldly claim that people have spent more time making the GHC build system work with this Cabal dependency than it would take stripping it off!

(In fact, I would try to do this right now if the GHC build system wouldn't take so long to compile even the smallest changes ...)

Herbert Valerio Riedel

10:32 a.m.

New subject: GHC API + Cabal API + Cabal version checks: is there a way out?

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

JP Moresmau

10:52 a.m.

New subject: GHC API + Cabal API + Cabal version checks: is there a way out?

Interesting: in the ghc-devs discussion, Duncan talks about a cabal-lib and a cabal-build-simple split ( http://www.haskell.org/pipermail/ghc-devs/2013-March/000821.html). That would solve my problem nicely (GHC could depend on cabal-lib only, that wouldn't have to change as often as cabal-build-simple). I don't see a trace of that split in 1.18, anybody knows if it's still on the map? And thanks everybody for the contributions, it looks I'm not the only one that had thought about that issue... JP On Fri, Sep 6, 2013 at 4:32 PM, Herbert Valerio Riedel wrote:

...

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

-- JP Moresmau http://jpmoresmau.blogspot.com/

Niklas Hambüchen

11:06 a.m.

New subject: GHC API + Cabal API + Cabal version checks: is there a way out?

We just had a short discussion on #ghc, I copy-paste: http://lpaste.net/92639 dcoutts_: nh2: Cabal does not depend on the ghc-pkg format. Cabal specifies a compiler-independent package registration format. GHC uses it in its external interface (and internally too). It uses the Cabal lib for the parser+printer because it's easier than making its own and keeping up with spec changes.. dcoutts_: type+parser+printer nh2: dcoutts_: would it still not be easier to make this package database specification a separate thing that both ghc and cabal can depend on? It seems to me that this would be much less a moving target than Cabal-the-build-system is dcoutts_: nh2: what does make sense is to split the Cabal lib into the Distribution.* bits and the Distribution.Simple.* bits dcoutts_: nh2: it's not a natural split hvr: nh2: btw, a related thread: http://www.haskell.org/pipermail/ghc-devs/2013-March/000800.html dcoutts_: nh2: there's a lot of types shared between the .cabal format and the InstalledPackageInfo type dcoutts_: as well as parser + printer infrastructure dcoutts_: nh2: it makes sense to keep that all together, that's the Distribution.* stuff dcoutts_: as I said, what does make sense to split (it's been deliberately kept mostly-separate) is the Distribution.Simple.* part dcoutts_: nh2: and we need a parser for that part, that's the dependency that's annoying thoughtpolice: so yes, i'm going to look into it today if at all possible nh2: dcoutts_: that makes sense. ghc does not depend on Distribution.PackageDescription either, right? dcoutts_: nh2: right, it doesn't need the source package type (PackageDescription), just the installed package type (InstalledPackageInfo) dcoutts_: nh2: but splitting these into different packages would not buy us much and it's not a natural split nh2: leaving away Distribution.Simple.*, the remaining part is already so small that it indeed looks like a small enough interface dcoutts_: nh2: it'd only help JP M if the remaining part (lets call it cabal-build-simple) could build with an earlier core part (lets call it cabal-lib) (in his request in http://www.haskell.org/pipermail/haskell-cafe/2013-September/108746.html) dcoutts_: nh2: and doesn't help me with my parser problems, we still cannot depend on a decent parser combinator lib dcoutts_: still have to use the crappy ReadP nh2: dcoutts_: Distribution.PackageDescription is the .cabal file format itself, right? Not sure if that should be part of the package DB spec, it changes more often and ghc can't make use of it nh2: why is it that you cannot depend on something better? dcoutts_: nh2: because ghc cannot depend on parsec easily dcoutts_: because it pulls in too many other things dcoutts_: the ghc devs objected to my suggestion dcoutts_: nh2: that's true but what does it really buy us if they're in separate packages? We still cannot guarantee to support JP M's request dcoutts_: e.g. in the switch to 1.18, there have been enough changes that we'd need the latest version of the InstalledPackageInfo hvr: dcoutts_: ...seems you have to explain that again everytime somebody brings it up =) nh2: dcoutts_: but do I not understand it right that if you put PackageDescription not into cabal-lib and only in Cabal, Cabal could actually depend on a proper parser since GHC doesn't depend on it any more? dcoutts_: nh2: it's not a monolithic parser dcoutts_: nh2: we have that Text class dcoutts_: with the combinator parsers for all the various types used in .cabal and installed package files dcoutts_: these types + parser/printer infrastructure are shared between the source and installed package files dcoutts_: so even if we split it, we still have the problem of needing a parser lib lemao: dcoutts_: I hear you wrt to the difficulties and mixed results of splitting Distribution.Simple at the same time that this GHC dependency on cabal is really problematic for all the reasons already discussed dcoutts_: lemao: I don't think splitting it would fix that lemao: dcoutts_: yes, I hear you. Maybe the right solution here is to have GHC own their own internal package info impl so Cabal and GHC can go their separate ways dcoutts_: you'd still have ghc depending on this smaller part, and Cabal/cabal-install would still depend on (usually) the latest version of that dcoutts_: lemao: but that's also not satisfactory (for cabal-lib to be a private dep of ghc) because ghc api exposes the InstalledPackageInfo type dcoutts_: it's not a private dependency of the ghc api package, it's a public dependency lemao: dcoutts_: I guess what I meant is that ghc-pkg package format/parser/etc would be a complete fork dcoutts_: which then means you cannot pass the InstalledPackageInfo from ghc api functions to anything else lemao: dcoutts_: at the same time that there are issues with the split there are real issues witht he current status quo dcoutts_: as well as meaning it'd get out of sync nh2: dcoutts_: InstalledPackageInfo looks like a very simple/straightforward type though dcoutts_: nh2: on it's own, but it uses a bunch of other types + their parsers+printers dcoutts_: nh2: and are we really saying that we could always work with old versions of this type, that we'd never need to depend on the latest version in the latest version of Cabal? dcoutts_: because if not, then we gain nothing lemao: dcoutts_, nh2: real question here, how often does the package info that matters for ghc actually changed in the past? dcoutts_: lemao: it does change occasionally dcoutts_: and it will change again dcoutts_: we have changes pending lemao: dcoutts_, nh2: I can see how most of the drivers for these changes come from cabal nh2: dcoutts_: I can't see many other types, there are only two: License (a simple enum) and Version. Everything else is String/Bool dcoutts_: nh2: PackageName, PackageId etc nh2: dcoutts_: are both string newtypes dcoutts_: nh2: but note also that it uses the same parser infrastructure nh2: dcoutts_: would you mind if I open a bug to discuss this? lemao: nh2: maybe what is needed here is a concrete proposal lemao: nh2: so this can be discussed in more detail? lemao: nh2: I guess a ticket would be a great start On 06/09/13 23:52, JP Moresmau wrote:

...

Interesting: in the ghc-devs discussion, Duncan talks about a cabal-lib and a cabal-build-simple split (http://www.haskell.org/pipermail/ghc-devs/2013-March/000821.html). That would solve my problem nicely (GHC could depend on cabal-lib only, that wouldn't have to change as often as cabal-build-simple). I don't see a trace of that split in 1.18, anybody knows if it's still on the map? And thanks everybody for the contributions, it looks I'm not the only one that had thought about that issue...

Alejandro Serrano Mena

10:54 a.m.

New subject: GHC API + Cabal API + Cabal version checks: is there a way out?

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

...

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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Yuri de Wit

11 a.m.

New subject: GHC API + Cabal API + Cabal version checks: is there a way out?

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 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

...
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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

JP Moresmau

11:04 a.m.

New subject: GHC API + Cabal API + Cabal version checks: is there a way out?

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 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
...
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

...
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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- JP Moresmau http://jpmoresmau.blogspot.com/

Niklas Hambüchen

11:19 a.m.

New subject: GHC API + Cabal API + Cabal version checks: is there a way out?

I have filed a GHC ticket under http://ghc.haskell.org/trac/ghc/ticket/8244 I hope this way we can find a solution soon. On 07/09/13 00:04, JP Moresmau wrote:

...

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...

Niklas Hambüchen

11:23 a.m.

New subject: GHC API + Cabal API + Cabal version checks: is there a way out?

It looks to me that technically it should be easy to split off the part required by GHC. Maybe somebody could just try that (currently it does not seem to take longer than a few hours) so that we have some basic proposal and momentum. On 07/09/13 00:04, JP Moresmau wrote:

...

Oh, I'm happy to help as well if somebody is needed to do the change

JP Moresmau

7 Sep 7 Sep

5:24 a.m.

New subject: GHC API + Cabal API + Cabal version checks: is there a way out?

I'll be happy to give it a shot! JP On Fri, Sep 6, 2013 at 5:23 PM, Niklas Hambüchen wrote:

...

It looks to me that technically it should be easy to split off the part required by GHC.

Maybe somebody could just try that (currently it does not seem to take longer than a few hours) so that we have some basic proposal and momentum.

On 07/09/13 00:04, JP Moresmau wrote:

...
Oh, I'm happy to help as well if somebody is needed to do the change

-- JP Moresmau http://jpmoresmau.blogspot.com/

Niklas Hambüchen

6:17 a.m.

New subject: GHC API + Cabal API + Cabal version checks: is there a way out?

Would you mind hanging around in #ghc when working on it? A few people found this interesting, so this might be useful to avoid duplicate effort. On Sat 07 Sep 2013 18:24:43 JST, JP Moresmau wrote:

...

I'll be happy to give it a shot!

Yuri de Wit

11 Sep 11 Sep

10:11 a.m.

New subject: GHC API + Cabal API + Cabal version checks: is there a way out?

That is a good point. I am usually there in #ghc with nickname lemao. Niklas is nh2 afaik. On Sat, Sep 7, 2013 at 7:17 AM, Niklas Hambüchen wrote:

...

Would you mind hanging around in #ghc when working on it?

A few people found this interesting, so this might be useful to avoid duplicate effort.

On Sat 07 Sep 2013 18:24:43 JST, JP Moresmau wrote:

...
I'll be happy to give it a shot!

4270

Age (days ago)

4275

Last active (days ago)

List overview

Download

16 comments

6 participants

participants (6)

Alejandro Serrano Mena
Herbert Valerio Riedel
JP Moresmau
Niklas Hambüchen
Roman Cheplyaka
Yuri de Wit