Thanks Oleg. Where is the best place to read about cabal's mental model of package databases (global and local), project files. etc? Just basic things like "what is a package database" and "how does writing a minimal package definition make a sandbox that protects you from X and Y".
I had a look at https://cabal.readthedocs.io/en/stable/cabal-context.html which is a good start, but doesn't explain enough concepts. Is there anything else I should look at? Thanks Simon On Tue, 14 Apr 2026 at 17:31, Oleg Grenrus via ghc-devs < [email protected]> wrote: > > why ghc-22 can know about `base` > > Because these are part of global package database. And since a decade ago > cabal-install treats global package database as immutable. And very likely > if you modify package database in _build, hadrian might get very confused. > > Yes, the immutability of global package database might be inconvenient for > the very few GHC hackers, but by making it practically impossible to modify > that database saves a lot of people from (accidentally) messing their > setups. > > >> Why you want to build and install a bunch of libraries? You most likely > don't want to do that. > > I think I really do > > I argue that if you don't really feel that you need to amend global > package database of your "main" global/default GHC, then you don't need to > amend the global package database of your WIP-GHC either. It might be the > very case that you don't work on "ordinary" projects i.e. which use cabal > as their build tool but are intended to be compiled with different GHC > versions, so you don't feel at home using cabal-install, writing package & > project definitions and changing to different GHC versions at will. But > please trust me that the non-stateless workflow of cabal-install is really > a lot better long term and actually allows you do more stuff > > Allow `cabal-install` manage (the local) package database for you. > > > All those see a bit complicated wrt > > FWIW, I also think that the invocations Tom mentioned are a lot more > complicated compared to writing minimal package definition > > cabal-version: 3.0 > name: my-test > version: 0 > > library > build-depends: base, hspec > exposed-modules: Foo.hs > > and `cabal build -w $HOME/code/HEAD-22/_build/.../ghc` and `cabal build -w > ghc` to compare the behavior with stock GHC etc. > > There are those six or so lines of "boilerplate setup", but they actually > do declare dependencies, so in case you have to return to this example > later, or share it with someone, it's all there in "runnable" format. > > - Oleg > > > On 4/10/26 22:09, Simon Peyton Jones via ghc-devs wrote: > > Thank you. All those see a bit complicated wrt > ghc-22 Foo.hs -package hspec > > I am curious about why ghc-22 can know about `base` and `containter` (all > safely tucked away in $HOME/code/HEAD-22/_build) but not about `hspec`. > > Simon > > On Fri, 10 Apr 2026 at 14:47, Tom Smeding via ghc-devs < > [email protected]> wrote: > >> Dear Simon, >> >> I do not know the answer to your question, but I do know a few >> workarounds using cabal that may or may not be helpful. >> >> Cabal lets you do this: >> >> $ cabal repl -b hspec -w ~/code/HEAD-22/_build/stage1/bin/ghc >> >> this creates a fake project with "hspec" as the list of dependencies, and >> starts a ghci session there. (You could also write something like `cabal >> repl -b 'hspec ==2.11.17, HUnit >= 1.6'` -- it's really a list of >> constraints.) Naturally, this doesn't work if you want to compile a file >> instead of opening ghci. >> >> One can work around this as follows (but see the warning below): >> >> $ cabal repl -b hspec -w ~/code/HEAD-22/_build/stage1/bin/ghc >> --repl-option=-fobject-code --repl-option=Foo.hs >> >> which does open ghci, but it compiles Foo.hs to an object file, which may >> sufficient for your use case. Warning: it seems that -fobject-code breaks >> the illusion that the fake project doesn't actually exist, as a >> `dist-newstyle` tree is created in the current directory, which you may >> need to clean up afterwards. >> Note: I used --repl-option twice instead of --repl-options (mind the S) >> once to allow spaces in Foo.hs. >> >> Another workaround which does allow you to avoid opening ghci but >> requires editing the test file, is to make it a "cabal script". [1] If I >> put the below (between the markers) in a file `test.hs`: >> >> ``` >> {- cabal: >> build-depends: base, hspec >> -} >> {- project: >> with-compiler: /path/to/some/ghc >> -} >> module M where >> x = 4 >> ``` >> >> and run: >> $ cabal build test.hs >> the thing is compiled to an object file, and I get an error from GHC that >> there was no Main module but there was a -o option so what did you want to >> do exactly. (If test.hs is a Main module, this works better, naturally). >> >> Apologies if this is not helpful, but perhaps at least one of these >> tricks was new to one of the readers of this list. >> >> - Tom >> >> [1]: https://cabal.readthedocs.io/en/stable/cabal-commands.html#cabal-run >> >> On 10/04/2026 09:22, Simon Peyton Jones via ghc-devs wrote: >> >> Why you want to build and install a bunch of libraries? You most likely >>> don't want to do that. >> >> >> I think I really do. Let's call my build #22 ghc-22 >> export ghc-22 $HOME/code/HEAD-22/_build/stage1/bin/ghc >> >> Then on any one of dozens of 5-line tests, given in tickets, I can say >> >> ghc-22 -c Foo.hs >> >> and ghc-22 already knows about base, ghc-internal, text, containers etc >> built by and for ghc-22. They are squirrelled away somewhere in >> $HOME/code/HEAD-22/_build >> >> It's like "batteries included": I already have `base` >> >> Now some has a test that needs `hspec`. I'd like to add `hspec` to the >> batteries in $HOME/code/HEAD-22/_build, so that after that I can always say >> ghc-22 -package hspec Foo.hs >> and away we go. >> >> Yes I could make a cabal project for a 5-line test, but that's more >> keystrokes. Is it difficult to just get it to treat `hspec` the same way >> that it treats `base` or `containers`? >> >> I know this isn't the intended use-case for cabal; it's just the use-case >> I have. >> >> Thanks >> >> Simon >> >> On Fri, 10 Apr 2026 at 05:01, Oleg Grenrus via ghc-devs < >> [email protected]> wrote: >> >>> Why you want to build and install a bunch of libraries? You most likely >>> don't want to do that. >>> >>> If you want to play with particular GHC version, create an ordinary >>> cabal package with dependencies you need, and point `cabal-install` to use >>> your HOME/code/HEAD-22/_build/stage1/bin/ghc >>> >>> There is nothing (noteworthy) special about `cabal repl -w >>> $HOME/code/HEAD-22/_build/stage1/bin/ghc`; as long as `cabal-install` is >>> concerned, it's just some GHC build. >>> >>> - Oleg >>> On 4/8/26 17:43, Simon Peyton Jones via ghc-devs wrote: >>> >>> Dear devs >>> >>> I have thirty or so builds of GHC on my disk. Sometimes I want to use >>> one build to build and install (for that build alone) a bunch of >>> libraries. If I do >>> cabal install hspec -w $HOME/code/HEAD-22/_build/stage1/bin/ghc >>> then Cabal rightly warns me >>> >>> Warning: The libraries were installed by creating a global GHC >>> environment >>> file at: >>> /home/simonpj/.ghc/x86_64-linux-9.15.20260309/environments/default >>> >>> >>> The presence of such an environment file is likely to confuse or break >>> other >>> >>> tools because it changes GHC's behaviour: it changes the default package >>> set >>> in ghc and ghci from its normal value (which is "all boot libraries"). >>> GHC >>> environment files are little-used and often not tested for. >>> >>> Question: how can I install the libraries in the build tree for >>> $HOME/code/HEAD-22? >>> After all, I think ghc-internal, base etc are all in that build-tree. >>> Surely hspec can be too? >>> >>> But how? >>> >>> Thanks! >>> >>> Simon >>> >>> _______________________________________________ >>> ghc-devs mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >>> _______________________________________________ >>> ghc-devs mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >> >> _______________________________________________ >> ghc-devs mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >> >> _______________________________________________ >> ghc-devs mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > > _______________________________________________ > ghc-devs mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > _______________________________________________ > ghc-devs mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
