OPAM Windows port

[Baneeishaque]

Is there any OPAM port for win64?

[dra27]

The work I'm doing in https://github.com/dra27/opam/tree/windows supports all four native Windows ports (i.e. the mingw64 and Microsoft C compilers in both 32 and 64 bit versions of each). I'm afraid it's not complete yet, though!

[XVilka]

Double of the #246 ?

[dra27]

@XVilka - more a refinement of #246 :)

[Chris00]

In case it is useful, I started a project to have a native Windows (Win64) build of OCaml to use in Appveyor. It also compiles OPAM (the dose 3 tarball symlink has to be worked around) but the resulting opam does not work, opam returns:

Fatal error:
# opam-version    1.3.0~dev3 (ecc8e2da0e46329834837631020bf4d3f7c94a9c)
# os              win32
opam: "create_process" failed on /bin/sh: No such file or directory
Backtrace:
  Raised by primitive operation at file "unix.ml", line 820, characters 2-157
  Called from file "core/opamProcess.ml", line 180, characters 4-118
  Called from file "core/opamProcess.ml", line 260, characters 2-110
  Called from file "core/opamProcess.ml", line 452, characters 10-32
  Called from file "core/opamSystem.ml", line 292, characters 6-124
  Called from file "core/opamSystem.ml", line 330, characters 14-38
  Called from file "solver/opamSolverConfig.ml", line 38, characters 7-41
  Called from file "camlinternalLazy.ml", line 25, characters 17-27
  Re-raised at file "camlinternalLazy.ml", line 32, characters 10-11
  Called from file "solver/opamSolverConfig.ml", line 244, characters 28-48
  Called from file "client/opamArg.ml", line 74, characters 2-1023
  Called from file "client/opamMain.ml", line 1334, characters 4-39
rm: cannot remove 'C:\\Users\\appveyor\\AppData\\Local\\Temp\\1\\opam-appveyor-96/command-96-5a61c5.err': Device or resource busy 
rm: cannot remove 'C:\\Users\\appveyor\\AppData\\Local\\Temp\\1\\opam-appveyor-96/command-96-5a61c5.out': Device or resource busy 
rm: cannot remove 'C:\\Users\\appveyor\\AppData\\Local\\Temp\\1\\opam-appveyor-96/command-96-5a61c5.err': Device or resource busy 
rm: cannot remove 'C:\\Users\\appveyor\\AppData\\Local\\Temp\\1\\opam-appveyor-96/command-96-5a61c5.out': Device or resource busy 
Fatal error: exception # opam-version    1.3.0~dev3 (ecc8e2da0e46329834837631020bf4d3f7c94a9c)
# os              win32
Cannot remove C:\Users\appveyor\AppData\Local\Temp\1\opam-appveyor-96 (error 1).
Raised at file "core/opamSystem.ml", line 29, characters 10-30
Called from file "set.ml", line 305, characters 38-41
Called from file "pervasives.ml", line 482, characters 30-33
Called from file "pervasives.ml", line 487, characters 2-15
Called from file "client/opamMain.ml", line 1563, characters 2-22
Command exited with code 2

[Chris00]

In case it is useful, the worries about ocamlfind not working on pure Windows are unfounded: ocamlfind requires Cygwin to be built but then happily works on pure Windows (I'll be glad this to be confirmed as there is no way to get rid of Cygwin on AppVeyor machines). The same goes for ocamlbuild (as long as the path to compilers does not contain space, i.e., use the short version of the dir for now). As for other packages, the ones using oasis build fine on pure Windows, even when using C bindings.

[XVilka]

Any updates on those patches? I see fork wasn't updating since November, 2015.

[dra27]

I'd been doing some related work on OCaml 4.03 - will be getting back to this fork shortly!

[Chris00]

👍

[braibant]

@Chris00 out of curiosity, do you know how your appveyor project compares with https://github.com/braibant/ocaml-windows-bootstrap?

[Chris00]

1. It builds OCaml with MSVC, not mingw — it uses Cygwin for the build but OCaml does not depend on it (the other scripts are CMD or .ml).
2. It is specifically designed for testing with AppVeyor (it provides scripts to easily do that — in particular one must properly set environment variables, there are many pitfalls to avoid in AppVeyor). It probably could be used to generate an installer for OCaml but that will need to be a contribution.
3. It aims to (eventually) use Windows OPAM to install packages (without Cygwin that is).

I only had a cursory look to your work, so correct me if needed.

[braibant]

Fair enough. I think that @protz use something inspired by my scripts to generate an installer, but I am not quite sure, and I used them to do some CI (but no AppVeyor).

[protz]

I use your scripts to bootstrap my opam setup... and then I use opam to install whatever packages are needed to re-build opam.

[aantron]

👍

[XVilka]

I see a lot of work was done in your fork @dra27. I hope it will be merged in the mainline at some point. This will change OCaml adoption in Windows world drastically.

[dra27]

It will hopefully be being rebased, completed and merged later this year and in early 2017 as I become a little more full time on it!

[soapdog]

Any news regarding this port?

[XVilka]

@soapdog this PR was merged, which is certainly a good news regarding Windows port #3155

[XVilka]

@dra27 have you considered to check also the clang-cl port instead or in addition to MSVC one? Google Chrome and Mozilla Firefox recently switched to it for forming official Windows binaries. It brings also all kinds of sanitizers support to Windows compiled binaries.

[dra27]

What problems do you expect that to solve?

[XVilka]

@dra27 mostly catching bugs in OCaml runtime at Windows with extensive clang tooling.

[dra27]

So not strictly of benefit to opam, then! There's remarkably little Windows-specific code in the OCaml runtime - the rest of it is already run through Clang's sanitizers in Inria's CI.

[dra27]

Full upstream support is (finally!) planned for opam 2.2. There is already excellent downstream support at https://fdopen.github.io/opam-repository-mingw/