tobil4sk

> cd _build/default/src/c/vendor/libuv I seem to remember that when I checked this when I built last time, it was completely empty or didn't exist. I will double check to confirm....

Hm, this also seems the same as #132? But was reported before opam 2.2.

With the verbose compilation output, I got a lot of compiler errors. I did some research and it lead me to this comment in a libuv issue: https://github.com/libuv/libuv/issues/1421#issuecomment-315405453 My build...

Hm, that issue I had was in an msys2 environment. When I set up opam with cygwin instead, I get this output from configure: ``` -ar... nofor x86_64-w64-mingw32 -lib... noor...

For cygwin, this entry was missing from my PATH (and from PATH in setup-ocaml), which is where `ar` is located: ``` /usr/x86_64-w64-mingw32/bin ``` The opam-repository script doesn't even add cygwin's...

`luv`'s build workflow [succeeds](https://github.com/tobil4sk/luv/actions/runs/10751020263/job/29817822544) with this patch to setup-ocaml: https://github.com/ocaml/setup-ocaml/pull/859. To reiterate, for a successful build it is necessary to have these values in `PATH`: - For msys2: `$MSYS2_ROOT/mingw64/bin` and...

This seems somewhat related to https://github.com/ocaml/setup-ocaml/issues/1008. To me the ideal solution seems to be for `opam env`/`opam exec` to take care of setting the `PATH` correctly so that it is...

Should mingw-w64-shims also add `/usr/x86_64-w64-mingw32/bin` to PATH maybe? It already adds `/usr/x86_64-w64-mingw32/sys-root/mingw/bin`: https://github.com/dra27/mingw-w64-shims/blob/3c4a82700d9b03443ad6f2927449f7a8f25a77cf/mingw-w64-shims.opam#L8 The problem is that the `luv` library builds a native library using autotools, and the configure script...

It turns out there was actually a [deeper issue](https://github.com/aantron/luv/pull/165) behind why the `/usr/x86_64-w64-mingw32/bin` was needed, and resolving that has removed the need for it. For `/bin`, the reason it is...

> Maybe an extra element on the files tag? Something like this is probably the best bet, since it provides compiler agnostic abstraction over the raw flags. It would require...