Monitor also ghc.shim file on Windows

[jasagredo]

On Linux, when changing the compiler cabal says:

File monitor 'compiler' changed: file /home/javier/.ghcup/bin/ghc

On Windows after this fix it will say:

File monitor 'compiler' changed: file C:\ghcup\bin\ghc.shim

which actually is the file that changes when GHCup switches versions.

QA

$ cabal init -n -m
$ cabal build dry-run
$ ghcup set ghc $OTHERVERSION
$ cabal build dry-run -v3
...
File monitor 'compiler' changed: file C:\ghcup\bin\ghc.shim

Template Α: This PR modifies behaviour or interface

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
  • Is the change significant? If so, remember to add significance: significant in the changelog file.
• The documentation has been updated, if necessary.
• Manual QA notes have been included.
• Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!)

[jasagredo]

I think adding a test that tests multiple GHC versions changing is out of the capabilities of the test setup, so I ask for permission to merge this without a test.

[hasufell]

To be honest... this is a huge hack.

Cabal shouldn't be required to know about this. It's an implementation detail of GHCup.

The culprit is that windows doesn't have reliable symbolic link support.

What cabal should really care about is the GHC version or even ABI. Can we not run ghc --numeric-version instead of hashing the file contents?

[jasagredo]

It is indeed a big hack. I am open to suggestions.

I think changing the whole mechanism for detecting changes from files changing to output of commands sounds like a big task, but it might indeed be the right way of solving this.

[hasufell]

what if the file doesn't exist?

[Kleidukos]

@jasagredo Considering the tricky nature of this PR, I think it would have been better to discuss it in a ticket beforehand and gather feedback from all parties.

[mpickering]

@jasagredo I do agree this is a bit hacky but it might be the best thing to do.

If you want to implement it like this, the correct way to do so would be to add this path to programMonitorFiles for ghc.

The other alternative, is to modify the caching logic for this step. Firstly you would need to split up the configCompilerEx function into two parts.

• The first part just calls requireProgramVersion to get the path to the ghcProg and ghcVersion.
• The second part (cached) does everything else that configure currently does.

How does that sound to you?

[jasagredo]

@Kleidukos Feel free to continue the discussion in the linked issue. I just thought it would be better for discussion to have the proposed change somewhere as it is barely 3 lines of code.

[jasagredo]

If you want to implement it like this, the correct way to do so would be to add this path to programMonitorFiles for ghc.

The way programMonitorFiles is used there it is assumed already that those files must be non-existent, see the function called:

-- | Creates a list of files to monitor when you search for a file which
-- unsuccessfully looked in @notFoundAtPaths@ before finding it at
-- @foundAtPath@.
monitorFileSearchPath :: [FilePath] -> FilePath -> [MonitorFilePath]
monitorFileSearchPath notFoundAtPaths foundAtPath =
  monitorFile foundAtPath
    : map monitorNonExistentFile notFoundAtPaths

So we would have to use some other new field for this.

[jasagredo]

An unrelated note: programMonitorFiles sounds like files that we want to monitor, like in this case ghc.shim. I think the use of this field would actually fit better with the name programMonitorsNotFoundAt.