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 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 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:
[...]
[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 package 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
We could go argue with the Win32 maintainer to put it back in. I have: https://github.com/haskell/win32/issues/208
But it is a simple FFI implementation so I would not mind just including it in git-annex.
... But also git-annex can depend on a version of Win32 before this breakage. I've made that change. It's perhaps only a stopgap, if something else that git-annex uses begins depending on the newer version of Win32 later.
Switching to LockFileEx seems like it might break interoperation with older git-annex versions?
Thanks. I see they seem be rather receptive to your suggestion. (I put in a thumbs up, too) The only issue I see is deciding on how to name the raw version of createFile. Is there some precedent in Haskell land as to naming conventions? C and Python would just prepend an underscore or two to the name without necessarily indicating that they would be thereby off limits ("internal"). Maybe something like
_raw_CreateFilewith or without the underscore in the beginning?I see that things are slowly moving ahead in that github issue. On a somewhat related note I was able to compile with stack on Windows with lts-19.13 by adding the following extra-deps to stack.yaml (starting from Win32 onward in the following patch):
Yes, that was the newest Win32 I was able to make things work with as stack wasn't able to resolve the cross-dependencies involving
Win32,directory,processandtimepackages otherwise. And if I remember correctly there was something calledhaskelinethat also had specific requirements.The necessary change will be in win32 2.13.3.1, which should be released in due course. And I've made a (so far untested) change to git-annex to support that version.
Thanks, Joey, for making the pull request in Win32 with the necessary changes to support git-annex's use case. I will be on the lookout for its next release and then as soon as possible try building git-annex with LTS 19 via stack. I'll then report my findings here if you have not already done something to that effect before me.
It seems there was a tiny typo in commit 472f5c142b063053828358a3031a2ca09a373127, hence the following simple correction is needed for the build to complete: