Changing the compiler on Windows is not detected

[jasagredo]

Describe the bug If a project is built with one compiler, and we switch to a different one with GHCup, the 'compiler' file monitor will not be considered as changing because cabal does not check the version of the compiler, only checks:

-- from Distribution.Client.ProjectPlanning.configureCompiler
      ( hcFlavor
      , hcPath
      , hcPkg
      , progsearchpath
      , packageConfigProgramPaths
      , packageConfigProgramPathExtra
      )

On Linux, it is unclear how this triggers a rebuild, I suspect because the hcPath points to the real path and not the symlink. But on Windows the ghc.exe file is not changed, but instead the ghc.shim file next to it.

It would probably be enough if instead of hcFlavor we checked the CompilerId which is CompilerId CompilerFlavor Version.

To Reproduce

$ ghcup set ghc $VER1
$ cabal build all --dry-run
$ ghcup set ghc $VER2
$ cabal build all --dry-run -v3 | grep "File monitor 'compiler' unchanged."

Expected behavior A change in compiler version should trigger a rebuild.

System information

• Windows
• cabal 3.14.1.1, any ghc

Additional context

[mpickering]

I think at this point the CompilerId it not known (it is the discovery of that which is cached).

[jasagredo]

On Linux, it seems detection of a change in GHC versions seems to be done by checking whether the ghc executable has changed. When using GHCup, the file will change when changing GHC versions as it is a symlink to the actual GHC.

On Windows however, we make use of the shim executable which looks in its same directory for a companion file ghc.shim that contains the path to the actual GHC. This is because Windows does not have reliable symlink support.

I think the simplest hack to make this behave on Windows is what I think in #10853, i.e. on Windows, adding the ghc.shim file to the list of files monitored for the ghc program.

However as @hasufell pointed out, this is a big hack, as the shim file is just an implementation detail of GHCup that cabal probably shouldn't be aware of.

His suggestion is to decide based on some more stable observable, such as the value returned by ghc --numeric-version. This implies a (I think) big-ish rework on how these monitors are implemented, but I agree it probably is the right thing to do.