Skip to content

Changing the compiler on Windows is not detected #10850

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
jasagredo opened this issue Mar 25, 2025 · 2 comments · May be fixed by #10853
Open

Changing the compiler on Windows is not detected #10850

jasagredo opened this issue Mar 25, 2025 · 2 comments · May be fixed by #10853
Labels
needs triage type: bug

Comments

@jasagredo
Copy link
Collaborator

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
Copy link
Collaborator

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

@jasagredo jasagredo linked a pull request Mar 25, 2025 that will close this issue
Monitor also ghc.shim file on Windows #10853
Open
6 tasks
@jasagredo
Copy link
Collaborator Author

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.

@jasagredo jasagredo linked a pull request Mar 26, 2025 that will close this issue
Open
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
needs triage type: bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Monitor also ghc.shim file on Windows jasagredo/cabal
2 participants
@mpickering @jasagredo