Friends You may remember a recent thread on ghc-devs about GHC and Cabal . In it I say how I feel I lack the “big picture” of how GHC and Cabal interact, and that my mental model is probably faulty. Tom Ellis took pity on me, and together we wrote this big-picture overview about how GHC and Cabal i…

[image] atravers: So have all the problems with cabal listed there been resolved or reduced? Let’s see: multi-package project support (build all packages in one go, test all packages in one go…) :white_check_mark: depend on experimental and unpublished packages directly, stored in Git r…

It is not intended as a replacement for the GHC user guide, nor the Cabal user guide Ok, but is there any hope of a new revision of the Cabal ‘proposal’ ? The proposal is also neither of those two documents. Pinning down the details of how GHC/Cabal interaction is supposed to work sounds like a sp…

May I clarify, is the document intended to describe the relationship between GHC and Cabal (the library) or (and/or?) the relationship between GHC and Cabal (the tool) (the executable provided by the cabal-install package? As I understand it, both Stack and Cabal (the tool) are built on top of Caba…

@simonpj Thanks for opening this thread! I believe the relationship between the cabal project and GHC is underdiscussed but also critical to the development of the ecosystem. The issues at play are not only technical (those are fun to solve!) but also organisational, and their presence has put stre…

In much the same way as: A Formal Specification of the Haskell 98 Module System did, perhaps a literate Haskell script or some other minimal executable or checkable specification can help here to reduce the appearances of ambiguities. If that works, then it could be used as a advisory document to…

I believe the meaning of the word “install” has also changed over time. Before we get to that we need to introduce another “cabal”. The proposal defines packages and how to build them but not exactly how to distribute them. This is where Hackage and the cabal command line tool come in. To avoid con…

[image] andreabedini: The solver also consults the package database and prefers to reuse already installed packages (the dependency solving happens at the package level) when allowed by the constraints. This seems a strange default today, but I assume it was to avoid recompiling and/or to avoid …

[image] tomjaguarpaw: I’m not sure if you’re saying that’s how cabal-install currently behaves, but if so then it definitely doesn’t seem to! While I had no intention to be sneaky, I admit I should have seen this confusion coming. The solver is actually shared between the v1 and v2 commands,…

After a cabal update I expect to have to recompile most of my dependencies for any local package I’m building. I wish it had the behaviour you describe instead, although I was informed that the “prefer newest” behaviour has the benefit of coming up with a deterministic install plan once you know th…

[image] simonpj: Read it as a consumer. Does it tell you stuff that is useful? (Apologies in advance for a very dumb question from a dumb user.) I at first skimmed this thread expecting it was nothing to do with me. I’m like My use case is I’m a hobbyist who writes small programs. […

Haskell Community

GHC and Cabal: the big picture

Learn

show post in topic

Home
Categories
Guidelines
Terms of Service
Privacy Policy

Powered by Discourse, best viewed with JavaScript enabled