Need to clarify on build and repl

[AVBharath10]

Question

Is there a supported way to make cabal repl <pkg> --repl-options=-fobject-code reuse the object files produced by a prior cabal build <pkg>, or is a full recompile expected because of the ephemeral component the REPL synthesizes?

Environment

• GHC: 9.2.7
• Cabal: (please add output of cabal --version)
• OS: macOS (Apple Silicon / Intel — please specify)
• Project: ~222-module library component, built inside a Nix shell

What I expected

If cabal build and cabal repl are configured with the same optimization level and the same way flags (including dynamic objects on macOS), I expected cabal repl --repl-options=-fobject-code to reuse the .o / .dyn_o / .hi files already produced by cabal build and skip recompilation.

What actually happens

Even when I align optimization levels, the REPL recompiles all 222 modules from scratch on every invocation.

Attempt 1 — --ghc-options="-O0" on both commands

$ cabal build beckn-spec --ghc-options="-O0"
... compiles all 222 modules ...
[222 of 222] Compiling Paths_beckn_spec

$ cabal repl beckn-spec --ghc-options="-O0" --repl-options=-fobject-code
Build profile: -w ghc-9.2.7 -O1
In order, the following will be built (use -v for more details):
 - beckn-spec-0.1.0.0 (lib) (ephemeral targets)
Preprocessing library for beckn-spec-0.1.0.0..
GHCi, version 9.2.7: https://www.haskell.org/ghc/  :? for help
[  1 of 222] Compiling Beckn.Types.Core.Metro.Common.DecimalValue
... full recompile ...

Two things stand out:

1. The Build profile: line still reports -O1, even though --ghc-options="-O0" was passed. My understanding is that --ghc-options is appended to the GHC command line but does not change Cabal's build profile / store hash. Is that correct?
2. The (ephemeral targets) note suggests the REPL is configured as a distinct component from the one cabal build produced, which I suspect is the actual reason no artifacts are reused.

Attempt 2 — setting optimization at the project level

I also tried setting it in cabal.project.local:

package beckn-spec
  optimization: False

(Will post the resulting Build profile: lines and recompilation behavior in a follow-up — running the experiment now.)

Specific questions

1. Is artifact reuse between cabal build <pkg> and cabal repl <pkg> --repl-options=-fobject-code a supported workflow in current Cabal, or is the ephemeral REPL component expected to always trigger a recompile?
2. If it is supported, what is the exact set of conditions that must hold for the cache hit to occur (optimization level, shared/-dynamic-too, profiling, ghc-options, etc.)?
3. Is there a way to ask Cabal to dump the configuration hash / GHC invocation it uses for both commands, so I can diff them and see precisely what is mismatched?
4. Are there known improvements in newer Cabal versions (3.10+, 3.12+) that affect this?

For context: with a 222-module library, a cold cabal repl takes several minutes, which makes iteration painful. I'm aware of ghcid as a workaround for the per-edit case, but I'd still like to understand whether the underlying artifact sharing is achievable.

Thanks!