dune build hangs under Windows

[nojb]

I am getting this when trying to build master under Windows:

...
ocamldep returned unexpected output for _build/default/src/stdune/either.ml:
-> required by src/stdune/.stdune.objs/either.ml.d
-> required by src/stdune/.stdune.objs/either.ml.all-deps
-> required by src/stdune/stdune.cmxa
-> required by bin/main_dune.exe
-> required by _build/install/default/bin/dune.exe
-> required by dune.install
...

and then it hangs a little while later.

• The particular file reported changes each time.
• I am starting from a clean tree (git clean -fdx) and using the ocaml bootstrap.ml method.
• It works fine if I pass -j 1
• Maybe related to Wait for all processes to terminate before starting a new build in watch mode #1299 ?

[ghost]

It might be related to the changes to the scheduler indeed. We recently started using system threads to acknowledge various source of events. Although given the way we use threads it should work the same between Unix and Windows.

I've seen similar transient errors in the past though. One things that is frustrating about ocamldep is that when it fails it fails silently and still returns with exit code 0.

[ghost]

One thing you could try is the following: look for Build.run ~cotext (Ok context.ocamldep) in src/ocamldep.ml, then replace it by:

Build.progn
   [ Build.action ~targets:[] (Copy (file, Path.relative (Path.of_string <temp-dir>) (Path.to_string file)))
   ; Build.run ...
   ]

then look at the file ocamldep saw for the reported file.

[nojb]

I did this, but am not sure what I am looking for...

[ghost]

I was wondering if ocamldep was seeing a truncated or inexistant .ml file for instance.

[ghost]

In which case it would output nothing. Thinking about it again, it's not going to help as the file copy will be done by Dune itself. We'd need to change the ocamldep command itslef to check that. You could try that by replacing get_ocaml_tool_exn "ocamldep" in src/context.ml by another command that saves the input somewhere.

[ghost]

That doesn't explain why it hangs though...

[ghost]

BTW, is it easy to reproduce? I.e. any chance you could bisect the issue to see if it is #1299 or another commit?

[nojb]

Yes, it happens every time. Will check which commit it is and come back here.

[nojb]

I think the culprit is 0c4503b.

[nojb]

Thanks for the quick fix!