The command tries to configure the environment for you. But the auto detection of msvc environment might not work any longer. I haven’t looked at it, after I’ve set it up for https://github.com/ocaml/ocaml-ci-scripts/ (that’s the purpose of the 4.09.0+msvc64c switch that you are trying to use). And now newer versions of Visual Studio are available…
I would strongly recommend to use the mingw64 version of the compiler as opposed to msvc64. For mingw64 you don’t need Visual Studio, and all the setup pain associated with it. While msvc64 builds most pure-ocaml packages it has trouble with packages that have C dependencies, because many packages rely on GCC-specific extensions and flags. Since mingw64 is based on GCC, a larger subset of C-dependent packages will work out-of-the-box.
Plus, I am not aware of any advantages of msvc64 over mingw64.
Anyway, if you have to use msvc64, I am sure we can get you running too.
It’s just a cmd prompt that has some environment variables set up, so you have the Visual C compiler (cl), linker (link), assembler (ml64) and the right system libraries.
You run this command prompt and from there you call c:/OCaml64/bin/bash.exe and that will give you a Cygwin shell with those variables set up.
I think this is one way that can solve your immediate errors, we can take it from there.
I would prefer not to use Cygwin, and be able to do OPAM and DUNE without it - since I don’t see how that integrates with VSCODE.
Now, in that Medium article he said: eval $(opam config env), but what I have done based on comments above are:
$ opam switch create . ocaml-variants.4.09.0+mingw64c -- no problem
$ eval $(opam env)
$ opam install merlin ocp-indent dune utop
all in cygwin (but as I said, I would like to avoid cygwin if possible)
The final result still is as error, but it is further along.
<><> Gathering sources ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
[biniou.1.2.1] found in cache
[camomile.1.0.2] found in cache
[charInfo_width.1.1.0] found in cache
[cmdliner.1.0.4] found in cache
[cppo.1.6.6] found in cache
[dune.2.1.2] found in cache
[dune-configurator.2.1.2] found in cache
[dune-private-libs.2.1.2] found in cache
[easy-format.1.3.2] found in cache
[lambda-term.2.0.3] found in cache
[lwt.5.1.1] found in cache
[lwt_log.1.1.1] found in cache
[lwt_react.1.1.3] found in cache
[merlin.3.3.3] found in cache
[mmap.1.1.0] found in cache
[ocamlbuild.0.14.0] found in cache
[ocamlfind.1.8.1] found in cache
[ocp-indent.1.8.1] found in cache
[ocplib-endian.1.0] found in cache
[react.1.2.1] found in cache
[result.1.4] found in cache
[topkg.1.0.1] found in cache
[utop.2.4.3] found in cache
[yojson.1.7.0] found in cache
[zed.2.0.4] found in cache
[ERROR] The sources of the following couldn't be obtained, aborting:
- dune-private-libs.2.1.2
- ocamlfind.1.8.1
Which is why I still want to get away from Cygwin.
Have you already tried https://esy.sh/ ?
They at least don’t use cygwin’s curl for downloading the files…
My question still stands, about how to reach my goal of VSCODE, dune integration with no cygwin.
Convince the developers of OCaml, ocamlfind and many other programs and libraries to switch to a different build system. As long as this won’t happened, you can’t avoid cygwin (or wsl).
During your daily development, you don’t have to deal with the cygwin terminal. Start a cygwin shell once and run
mkshortcut -a '"C:/path/wherever/vscode/is/installed/Code.exe"' -D -n "Vscode-Link" /usr/local/bin/ocaml-env-win.exe
It will create a link called “Vscode-Link” on your Desktop. If you use this link to start VScode, your environment is properly set up for your current opam switch. You won’t notice any difference, if the gcc toolchain or the msvc toolchain is used internally (as long as your project doesn’t include c files).
One alternative to creating a link like @fdopen suggests, is to start VS Code from within a Cygwin shell. You can run code your_file.ml from the shell and VS Code will open with the correct environment set up.
The setup that I’ve used uses the Reason VS Code extension with the following settings:
All of this is fascinating, and I really appreciate the info. I am going to go back and do some research with esy and then compare it to the dune build process.
Not clear where the symlink or the cygwin VSCODE terminal is better, I suspect the first supports npm run commands.
