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]
