[opam-devel] OPAM on Windows (1.3 Roadmap)

[Fabrice Le Fessant]

On Wed, Nov 5, 2014 at 7:06 PM, David Allsopp
<david.allsopp at metastack.com> wrote:
> Although Windows has them, Windows and Unix process groups aren't quite the same concept. I expect you want more the behaviour of Unix.waitpid (-1) (any child) which is sort of what I implemented in my branch. In fact, the way waiting works under Windows, the stub I implemented specifically waits for any one of a list of PIDs to terminate.

That's also what is done in ocp-build to work on Windows, you have to
maintain a list of the processes you created with create_process, and
then wait on the list.

> But unless you guarantee that all 700/800 packages in OPAM do the same thing, at some point you will need a "real" environment - make, patch, m4, etc (you can't even get as far as findlib without m4) and ocamlopt's need for a C compiler, or at least an assembler, is never far away - and the two MSVC ports will *always* require you to install the Windows SDK separately to get the Microsoft assembler (I don't think packaging that in other setups is permitted under the licence).

OcpWin solves this problem by coming with its own version
(minimalized) of MinGW. Unfortunately, it then conflicts with the one
installed on Cygwin. We still have to find a workaround for this
problem.

>> * Test & fix on Windows
>> > "Cygwin, then, maybe, native." I'm afraid implies a crucial
>> > misunderstanding of how OCaml-on-Windows works.

I think Sylvain's remark is more about the fact that "Cygwin" is a
direct port (you compile from Cygwin to Cygwin), whereas "native",
when generated on Cygwin, is actually a cross-compilation (you are
generating code for "native" Windows, and these tools have problems
when running under Cygwin). From my experience, you then reach a
limitation of some of OCaml build tools (ocaml itself, then ocamlbuild
and other ones), and have to start patching a lot of stuff... Nothing
impossible, though a lot of uninteresting work...

When we decided to work on OcpWin, we had another approach: instead of
cross-compiling packages (either from Linux or from Cygwin), we
decided to compile them directly under native Windows. The idea is to
get used to what native Windows programmers are going to deal with,
and to try to fix these problems, instead of hiding them behind
Cygwin. It's very frustrating, but at least, I hope the result will be
more "natural" for them this way (for now, we have a lot of .bat files
:-) ).

--Fabrice