Wrong stubs are used when opam sources are embedded in a dune workspace

[emillon]

Hi,

We're using the opam libraries in a project. These libraries are not installed through opam, they are vendored within a dune workspace. The resulting binary fails at runtime on Windows with:

           (Failure "Windows only. This function isn't implemented.")
           Raised at Stdlib.failwith in file "stdlib.ml", line 29, characters 17-33
           Called from OpamStd.OpamSys.system in file "duniverse/opam/src/core/opamStd.ml" (inlined), line 850, characters 15-54
           Called from OpamProcess.cygwin_create_process_env.f in file "duniverse/opam/src/core/opamProcess.ml", line 159, characters 37-60
           Called from OpamStd.OpamList.filter_map.loop in file "duniverse/opam/src/core/opamStd.ml", line 129, characters 14-17
           Called from OpamProcess.cygwin_create_process_env in file "duniverse/opam/src/core/opamProcess.ml", line 183, characters 12-41

My understanding is that opamStubs.ml.dummy are selected because the fallback rules are triggering. I think that this does not happen in the "usual" build route because of what happens with ./configure but I'm curious to see if opam can support this use case better (the fallback behaviour could be to let dune detect the OS, for example).

Thanks!

[dra27]

I should have a look at the current state of enabled_if support in Dune - the fallback files were added precisely to allow this kind of use to work on Linux so it's time to have a better look at Windows.