<div dir="ltr">I'll join in thanking you for making this list, Thomas.<div><br></div><div>I consider this the 2nd most important issue to the health of the OCaml ecosystem, right after multicore.</div><div><br></div><div>Unfortunately, we don't have the feedback of heavy windows users, because those have been selected out of the OCaml ecosystem. However, looking at just about every language out there, I think the ultimate goal has to be first class Windows support. This is my opinion at least. Cygwin is ok for now, but the aim has to be full windows support if OCaml is going to be seen as a viable option by the majority of the enterprise crowd. That means eventually getting rid of every Unix-ism out there, starting with ocamlbuild and ocamlfind, moving on to opam, and then making a curated list of packages on opam that build on windows. In fact, we should have a separate list for packages that build on cygwin, and one for packages that build on native windows, and we should encourage developers to move towards the latter list.</div><div><br></div><div>As an aside, if you're trying to install cygwin on a windows VM (such as the ones Microsoft distributes freely) and getting errors, it might have to do with symlinks. Cygwin has 3 modes of emulating symlinks on windows, and it can get fooled by the VM into thinking it has low-level support that isn't really there. All symlinks are then read as regular files, messing up just about everything. Therefore, before installing cygwin, set the environment variable CYGWIN to 'winsymlinks:lnk' in the windows environment.</div><div><br></div><div>-Yotam</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 29, 2015 at 3:00 PM, Török Edwin <span dir="ltr"><<a href="mailto:edwin+ml-ocaml@etorok.net" target="_blank">edwin+ml-ocaml@etorok.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 05/29/2015 06:10 PM, Thomas Braibant wrote:<br>
> Hi,<br>
><br>
> Thanks for joining this working group. Its goal is to find out how to<br>
> improve the state of OCaml and its ecosystem on Windows.<br>
><br>
> Some of the tasks that we might address (this list is by no mean<br>
> meant to be exhaustive nor normative):<br>
><br>
> - Gather information from the community about the use of the various<br>
> versions of OCaml available on Windows, and understand what kind of<br>
> environment people are working with. (BTW, I think a good way to get<br>
> the discussion rolling might be to describe each other's setup to use<br>
> OCaml on Windows.)<br>
<br>
</span>I don't use Windows myself at all, but I've been recently asked how to build an OCaml application on windows.<br>
Here is my very short experience with OCaml on Windows:<br>
- I used WODI with Cygwin64/Cygwin32 and OCaml 4.02.1 due to the large number of OCaml and C libraries available (notably Lwt and OpenSSL)<br>
- I tried to build my application however it failed due to path errors (more on this below)<br>
- I tried building opam from git, and it succeeded, although almost any package I tried to opam install failed to build<br>
- for some reason Cygwin64 executables keep crashing<br>
- I gave up after WODI was shutdown, waiting until opam has official Windows support<br>
<br>
Path errors<br>
-----------<br>
<br>
The errors looked like this, and it took me a while to figure out that this is because the build system is Cygwin but ocamlfind is a Win32 application<br>
and has no knowledge of what /cygdrive is:<br>
ocamlfind: Bad configuration: Cannot mkdir /cygdrive/c/libre/source/_build/lib/ocaml/site-lib\re because a path component does not exist or is not a directory<br>
File "<a href="http://dynlink_wrapper.ml" target="_blank">dynlink_wrapper.ml</a>", line 1, characters 13-14: Illegal character (\000)<br>
<br>
I worked this around by using `cygpath -m` in my build system in a few places, normalizing all paths to use / and replacing symlinks with cp.<br>
<br>
The path separators are also mixed (/ vs \, because build system uses / in queries like `pwd`, and Filename.concat uses \), but IIRC this actually worked.<br>
I think native Win32 apps might support a path made all of / these days, not sure why we have to go through all the trouble of trying to use \, but as a Unix person I probably miss some details here.<br>
<br>
Cygwin64 unreliability<br>
----------------------<br>
<br>
I don't know if the bug is in Windows, Cygwin64 or my VM configuration but the build system itself crashes a lot and randomly<br>
(there seems to be plenty of RAM available).<br>
Even things like make.exe or rm.exe crash with: segfault, fork: resource unavailable, exit code -1073741819.<br>
Restarting the cygwin shell helps sometimes but the errors are soon back, even when using just make -j1.<br>
The situation was bad enough that I had to repeat the build 4-5 times until it finally succeeded as it kept crashing in different places.<br>
Someone else tried WODI32 and didn't see such errors there, so that seems like a more reliable build system.<br>
Was about to report this as a bug in Cygwin64, but next week WODI was shutdown so that ended my Windows testing as well.<br>
<br>
Functions not implemented in Unix module<br>
----------------------------------------<br>
<br>
Although the build system was cygwin I got a native Win32 executable apparently, as it failed at runtime as various functions from the Unix module are not implemented.<br>
Luckily this is all well documented, so after adding some conditional code I was able to make some progress. Would be better if I could override these functions<br>
with a dummy implementation to make sure I don't get runtime errors.<br>
<span class=""><br>
><br>
> - Finalize OPAM support for Windows (this is listed on the OPAM 1.3<br>
> roadmap). When this support is in place, many OCaml packages should<br>
> work out of the box (with the proviso that many packages assume a<br>
> unix-ish environment for their build system).<br>
<br>
</span>Is there a way to have the build system and ocamlfind/ocamlopt/ocamlc agree on the format of paths?<br>
(i.e. either both of them are Cygwin or both of them native Win32 apps but not a mix)<br>
<span class=""><br>
><br>
> - Discuss how to help package developers improve Windows support. One<br>
> way to do that could be to provide know-how about how to setup<br>
> continuous integration on services like Appveyor to check that<br>
> packages build on typical Windows setups.<br>
><br>
> - Find a solution for users of WODI, the GODI based OCaml<br>
> distribution for Windows, which has been shutdown. WODI was able to<br>
> compile OCaml related software (using Cygwin as an environment), but<br>
> was also able to install binary packages. (In some cases, some<br>
> non-trivial patches were applied to make package usable on Windows.)<br>
> Some of the sources needed to use WODI are still available, but the<br>
> system does not work out of the box now that the server has gone<br>
> offline. With a little work, we might be able to bring it back, to<br>
> smooth the transition.<br>
><br>
> - Discuss the state of cross compilation to Windows.<br>
<br>
</span>This seems similar to the Android cross-compilation repository:<br>
<a href="https://github.com/vouillon/opam-windows-repository" target="_blank">https://github.com/vouillon/opam-windows-repository</a><br>
<br>
Best regards,<br>
--Edwin<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
wg-windows mailing list<br>
<a href="mailto:wg-windows@lists.ocaml.org">wg-windows@lists.ocaml.org</a><br>
<a href="http://lists.ocaml.org/listinfo/wg-windows" target="_blank">http://lists.ocaml.org/listinfo/wg-windows</a><br>
</div></div></blockquote></div><br></div>