OCaml 5 seems to sort of support Windows, vaguely. As far as I can see it uses an internal cygwin environment so it’s still keeping Windows at arms length. Presumably that is because so many packages assume Unix.
I’m trying to build one of those packages. It doesn’t use Dune, and its Makefile only works in a POSIX-like environment (it uses rm -f, /dev/null, etc.).
When I install it via opam install . it works fine, presumably because it runs it in some kind of cygwin shell. However if I just make install then I run into the Makefile compatibility issues.
I want to debug something in the build process, so my question is how can I run make install in the same way that OPAM does. I’m imagining something like opam exec cygwin or similar that would put my in some kind of cygwin shell where /dev/null exists and rm -f works.
The OCaml compiler itself requires a posix-ish environment to be built (configure script, makefile) but note that by default, all the resulting binaries are windows native binaries.
I haven’t tried, but i think opam exec -- bash should work. If not, the builtin Cygwin installation is located in C:\Users\<user>\AppData\Local\opam\.cygwin (aka. %LocalAppData%\opam\.cygwin) and you should be able to find the Cygwin terminal emulator somewhere in there
Yeah I did try that but it actually starts Bash in WSL! I think Microsoft has aliased bash to do that.
So I tried opam exec -- “C:/Users/Tim/AppData/Local/opam/.cygwin/root/bin/bash.exe” and that does start a cygwin Bash shell, but I don’t have rm or ls available. Seems like it doesn’t set PATH correctly because they are in that bin directory. Hmm.
As @kit-ty-kate notes, all the binaries produced are indeed native Windows binaries. The rationale behind Windows opam is that one is trying to produce native Windows software, and therefore using native Windows tools, so the internal Cygwin environment is there for one’s dependencies but not intended for development. Debugging a broken dependency unfortunately sits in a grey area, therefore!
You can indeed run bash -l to use the internal Cygwin installation. It’s also possible to install Cygwin as normal (e.g. to its default C:\cygwin64) and to instruct opam to use that installation, instead of managing an internal one. There’s nothing wrong with using or editing the internal Cygwin installation, the only caveat is that opam doesn’t prompt when making changes to an internal installation, but it will ask before making changes to your own external Cygwin or MSYS2 installation.
so the internal Cygwin environment is there for one’s dependencies but not intended for development
Ahhh interesting. I think that’s where the thing I’m debugging is going wrong then. It’s a compiler that embeds an absolute path to its standard library at build time. Because it’s a dependency, it’s running in cygwin so it finds this path: /cygdrive/c/Users/Tim/AppData/Local/opam/default/share/lem/library, but then in another project when it runs lem I guess it isn’t running in cygwin so that path doesn’t exist - it doesn’t look in C:\Users\Tim\AppData\Local\opam\default\share\lem\library. That sucks. I can’t think of an immediately obvious non-hacky solution either.
I don’t quite understand why that happens though because the other project is also a dependency…