Re: [Haskell-cafe] 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 m...@nh2.me 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! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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 m...@nh2.me 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/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GHC API + Cabal API + Cabal version checks: is there a way out?
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/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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 m...@nh2.me [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 signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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 ...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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 h...@gnu.org 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/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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
Re: [Haskell-cafe] 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 yde...@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 trup...@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 h...@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@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/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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 h...@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@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
Re: [Haskell-cafe] 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 trup...@gmail.comwrote: 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 h...@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@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
Re: [Haskell-cafe] 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... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
