not to be the bringer of bad news re: Windows, yet here we are

This commit is contained in:
jkniiv 2022-07-09 08:23:18 +00:00 committed by admin
parent 4f8b9f50f8
commit 92efe0b8e2

View file

@ -0,0 +1,55 @@
I was going to report a bug with the transition to lts-19.13 in stack.yaml as I couldn't
get for instance commit [[!commit d2bc2683173ca1ade437aa294b26fd5e54353a55]] "lts-19.13 (ghc 9.0.2)"
that introduced it to compile on windows (with stack). But then I procrastinated too long and commit
[[!commit d01530ac21aead6607085b5cc90b62a52acd03a9]] came along which reverted the transition and
went back to lts-18.13 due to Joey having trouble getting ghc 9.0.2 to install. That was kind of fortunate
to me because I didn't want to be the bringer of bad news regarding Windows in a bug report setting.
The problem with compiling with LTS 19 on Windows is the following:
[[!format sh """
[...]
[109 of 670] Compiling Utility.LockFile.Windows
Utility\LockFile\Windows.hs:64:17: error:
* Variable not in scope:
c_CreateFile
:: LPTSTR
-> AccessMode
-> ShareMode
-> GHC.Ptr.Ptr a0
-> CreateMode
-> FileAttributeOrFlag
-> GHC.Ptr.Ptr a1
-> IO HANDLE
* Perhaps you meant `createFile' (imported from System.Win32.File)
|
64 | c_CreateFile c_f gENERIC_READ sharemode security_attributes
| ^^^^^^^^^^^^
Completed 229 action(s).
-- While building package git-annex-10.20220624 (scroll up to its section to see the error) using:
C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-220630-d2bc26831\.stack-work\dist\d53b6a14\setup\setup --builddir=.stack-work\dist\d53b6a14 build exe:git-annex --ghc-options " -fdiagnostics-color=always"
Process exited with code: ExitFailure 1
"""]]
I digged into this and it turned out that as of Win32-2.12.0.0 it does not include those bindings
anymore that begin with `c_` in its exports and considers them as internal details. Unfortunately in
System.Win32.File the alternative, `createFile`, is a "cooked" API in the sense that if there are
intermittent errors opening the file there is some Haskell code that busy-waits on behalf of the user.
But according to Joey that is undesirable for a lockfile implementation (.\Utility\LockFile\Windows.hs:53):
```
- Note that createFile busy-waits to try to avoid failing when some other
- process briefly has a file open. But that would make checking locks
- much more expensive, so is not done here. Thus, the use of c_CreateFile.
```
So what to do when the authors of module Win32 pull the rug from under you? Should we perhaps weave
our own tiny c_CreateFile API with FFI, or, could we do without it and use one of the implementations
using Windows LockFileEx, for instance the one by my compatriot: <https://hackage.haskell.org/package/lukko>
[[!meta title="windows: prepare for System.Win32.File not exporting c_ entities"]]
[[!meta author=jkniiv]