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 [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 [email protected]
_______________________________________________
ghc-devs mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to