Support Windows #295
Comments
On Windows, execvp creates a separate process, which can confuse dune when it is waiting for the mdx process. This causes it to miss that the output file has been created. This affects mdx's test suite and possibly users of the mdx stanza. Instead we create a process and immediately wait for it in the parent. See realworldocaml#295, ocaml/dune#3849.
On Windows, execvp creates a separate process, which can confuse dune when it is waiting for the mdx process. This causes it to miss that the output file has been created. This affects mdx's test suite and possibly users of the mdx stanza. Instead we create a process and immediately wait for it in the parent. See realworldocaml#295, ocaml/dune#3849.
On Windows, execvp creates a separate process, which can confuse dune when it is waiting for the mdx process. This causes it to miss that the output file has been created. This affects mdx's test suite and possibly users of the mdx stanza. Instead we create a process and immediately wait for it in the parent. See realworldocaml#295, ocaml/dune#3849.
|
For point 3, this is not what's happening: execvp doesn't fail silently (when it fails, it raises an exception) but it reaches a state where it's a new process so dune doesn't know about it, and its outputs are closed so it cannot print anything. #299 fixes that! |
|
For cram-style tests, we expect something like a posix shell so it's ok to rely on the presence of sh and use things like echo, for loops, etc. |
On Windows, execvp creates a separate process, which can confuse dune when it is waiting for the mdx process. This causes it to miss that the output file has been created. This affects mdx's test suite and possibly users of the mdx stanza. Instead we create a process and immediately wait for it in the parent. See realworldocaml#295, ocaml/dune#3849.
On Windows, execvp creates a separate process, which can confuse dune when it is waiting for the mdx process. This causes it to miss that the output file has been created. This affects mdx's test suite and possibly users of the mdx stanza. Instead we create a process and immediately wait for it in the parent. See realworldocaml#295, ocaml/dune#3849.
On Windows, execvp creates a separate process, which can confuse dune when it is waiting for the mdx process. This causes it to miss that the output file has been created. This affects mdx's test suite and possibly users of the mdx stanza. Instead we create a process and immediately wait for it in the parent. See realworldocaml#295, ocaml/dune#3849.
|
Hello! Bumping this. For context; Eio tests run with mdx. We recently included a Select based backend for Windows, enabling Eio to work on Windows. This issue is a blocker for Eio 1.0. It'd be nice to fix it before ideally, so we can be reasonably sure the Windows backend works (and fix issues we might run into). Happy to help with testing or other ways we can. |
|
Hi. What's not working in the context of eio, precisely? |
|
Let me get back to this next week (vacationing this week) as I’ll try to get the Eio mdx tests working. I suspect most of the issues can be worked around. |
Currently, Mdx on Windows doesn't work well:
Line endings: Fix end of line parsing on Windows #294
Cram blocks don't work because Mdx is calling
sh.Calling ocaml-mdx-test doesn't work every time
argv0 cannot be trusted, also Mdx doesn't control how its installed and shouldn't. PATH is the right abstraction here.
In Mdx's testsuite, Dune gives us a path containing
/, Windows'execveexits without warning and nothing happen.In Mdx's testsuite
dune.incfiles are changed because of line encodingmliunit tests are failing because of line encodingmdx-test/*tests use POSIX shell features (echo, heredoc,forloops) and unix tools (ls,seq)I'm using Mdx in Odoc's testsuite and I'd like to run tests on Windows.
The text was updated successfully, but these errors were encountered: