> > I think Simon has a point. I really do not enjoy creating a new throwaway > project for every small reproducer I want to test.
My (clearly faulty) mental model is this. - I have a particular stage2 compiler, say $(GHC). Maybe built in my build tree, maybe installed. - If I say `$(GHC) -package primitive`, it right says "I don't know about primitiver" - I expect to be able to say `cabal install primitive --with-compiler=$(GHC)`, to extend my $(GHC) with the package `primitive`. - Thereafter I expect `$(GHC) -package primitive` to work -- after all, I have extended GHC to know about it. If I'm in a cabal project then these installed-by-default packages shouldn't make any difference; cabal will control everything. I'm sure it used to be like this, but something has changed, and I'm not sure why. Clearly my model of cabal is faulty, but I don't know how to get an accurate one. Is there a writeup I can read? e.g. What is the "environments" file? Why does it fail to find Prelude? Would it be possible to support the simple story above, as well? Simon On Tue, 9 Jul 2024 at 13:23, Sebastian Graf <sgraf1...@gmail.com> wrote: > Hi Simon, Hi Matt, > > I think Simon has a point. I really do not enjoy creating a new throwaway > project for every small reproducer I want to test. > A cabal project means that I can't simply pass `-fforce-recomp > -ddump-simpl -O` to a GHC invocation, for example. > Instead I have to create a cabal file and remember all the fields that > need to be set. (Or <enter> myself through a perceived 30 step wizard with > `cabal new`, only to find that I have to open the file anyway to tweak > build-depends...) > > Stupid as it may be, that subconsciously really affects my willingness to > tackle an issue. > > Presumably this can be solved through some amount of automation/scripting. > Perhaps it would be enough to share these scripts in a prominent location, > for example the Wiki. > Alternatively, I think I would enjoy something like `nix-shell -p`, where > I can just fire up a temporary shell with all the deps in a locally visible > package db. That way I could keep calling `ghc` directly. > > (Not that I suffer *much* from this issue at the moment anyway.) > > Sebastian > > Am Di., 9. Juli 2024 um 11:21 Uhr schrieb Matthew Pickering < > matthewtpicker...@gmail.com>: > >> `cabal install --lib` is very hard to use properly. I would advise >> against it. >> >> It is much easier to create a simple cabal project and use normal >> cabal build commands. I packaged things in a repo for you. >> >> https://github.com/mpickering/t25064 >> >> ``` >> cabal build -w ghc-9.6.2 (fails) >> cabal build -w /path/to/devel/compiler (fails with error message) >> ``` >> >> Matt >> >> On Tue, Jul 9, 2024 at 9:58 AM Simon Peyton Jones >> <simon.peytonjo...@gmail.com> wrote: >> > >> > Friends >> > >> > I'm trying to repro #25064 with my development build of GHC. The test >> case depends on packages `primitive` and `hashtables`. So I try this (see >> below). >> > >> > Alas, apparently after the `cabal install`, it can't find Prelude. >> > >> > What should I do? I tried removing the "environments" file, whatever >> that is, which then meant it could find Prelude -- but the libraries were >> no longer installed. >> > >> > I lack a decent model of what is going on with installing packages for >> my development builds. Is there a write up anywhere? >> > >> > Thanks >> > >> > Simon >> > >> > >> > bash$ cabal install --lib hashtables primitive --with-compiler >> $HOME/code/HEAD/$s2 >> > Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.10.1.0 >> supports >> > 'ghc' version < 9.8): /home/simonpj/code/HEAD/_build/stage1/bin/ghc is >> version >> > 9.11.20240517 >> > Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.10.1.0 >> supports >> > 'ghc' version < 9.8): /home/simonpj/code/HEAD/_build/stage1/bin/ghc is >> version >> > 9.11.20240517 >> > Resolving dependencies... >> > bash$ ~/code/HEAD/$s2 -c T25064.hs >> > Loaded package environment from >> > T25064.hs:1:8: error: [ ]8;; >> https://errors.haskell.org/messages/GHC-87110 \GHC-87110 ]8;; \] >> > Could not load module ‘Prelude’. >> > It is a member of the hidden package ‘base-4.20.0.0’. >> > Use -v to see a list of the files searched for. >> > | >> > 1 | module Bug where >> > | ^^^ >> > >> > bash$ rm >> /home/simonpj/.ghc/x86_64-linux-9.11.20240517/environments/default >> > bash$ ~/code/HEAD/$s2 -c T25064.hs >> > T25064.hs:3:1: error: [ ]8;; >> https://errors.haskell.org/messages/GHC-61948 \GHC-61948 ]8;; \] >> > Could not find module ‘Control.Monad.Primitive’. >> > Perhaps you meant Control.Monad.Writer (from mtl-2.3.1) >> > Use -v to see a list of the files searched for. >> > | >> > 3 | import Control.Monad.Primitive >> > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> > >> > T25064.hs:4:1: error: [ ]8;; >> https://errors.haskell.org/messages/GHC-87110 \GHC-87110 ]8;; \] >> > Could not find module ‘Data.HashTable.ST.Basic’. >> > Use -v to see a list of the files searched for. >> > | >> > 4 | import qualified Data.HashTable.ST.Basic as H >> > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> > >> > >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs@haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
