Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Windows #295

Open
Julow opened this issue Oct 20, 2020 · 5 comments
Open

Support Windows #295

Julow opened this issue Oct 20, 2020 · 5 comments
Labels
Kind/Feature-request New feature or request

Comments

@Julow
Copy link
Collaborator

Julow commented Oct 20, 2020

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' execve exits without warning and nothing happen.

  • In Mdx's testsuite

    • dune.inc files are changed because of line encoding
    • mli unit tests are failing because of line encoding
    • mdx-test/* tests use POSIX shell features (echo, heredoc, for loops) and unix tools (ls, seq)

I'm using Mdx in Odoc's testsuite and I'd like to run tests on Windows.

emillon added a commit to emillon/mdx that referenced this issue Nov 13, 2020
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.
emillon added a commit to emillon/mdx that referenced this issue Nov 13, 2020
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.
emillon added a commit to emillon/mdx that referenced this issue Nov 13, 2020
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.
@emillon
Copy link
Contributor

emillon commented Nov 13, 2020

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!

@emillon
Copy link
Contributor

emillon commented Nov 13, 2020

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.

emillon added a commit to emillon/mdx that referenced this issue Nov 16, 2020
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.
emillon added a commit to emillon/mdx that referenced this issue Nov 18, 2020
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.
emillon added a commit to emillon/mdx that referenced this issue Nov 18, 2020
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.
@gpetiot gpetiot added the Kind/Feature-request New feature or request label Dec 22, 2020
@Sudha247
Copy link

Sudha247 commented Jul 4, 2023

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.

cc @talex5 @polytypic

@emillon
Copy link
Contributor

emillon commented Jul 4, 2023

Hi.
I don't think that this issue is properly scoped at the moment (in the sense that we can't easily close it), but mdx works on windows. There used to be an issue with stray programs, fixed in #299. Cram tests are tricky to do in a portable way but that's not really a problem with mdx itself. md programs should work.

What's not working in the context of eio, precisely?

@polytypic
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Kind/Feature-request New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants