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

[David Allsopp]

Fabrice Le Fessant wrote:
> On Wed, Nov 5, 2014 at 7:06 PM, David Allsopp
> <david.allsopp at metastack.com> wrote:
> > 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.

Indeed - though, as someone using and developing on Windows pretty much all the time, I have yet to see this "problem" (I mean the "problem" of needing to install either Cygwin or MSYS, not the conflict). It only seems a problem in the eyes of people who don't use Windows or are incapable of following a couple more steps than simply being able to run sudo apt-get install ocaml!

If you are going to essentially embed all the tools, it's also worth having some kind of option to allow it to use those already installed.

> >> * 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...

What limitations do you mean with ocaml? The only thing necessary to get ocamlbuild to work is to ensure that it can find Cygwin's sh.exe and then the only resulting "complexity" is to ensure that you use forward-slashed paths to prevent escaping problems. In the simplest sense, putting C:\Cygwin\bin in the PATH simply fixes it - I actually do something slightly more complicated and just symlink the executables from Cygwin which I want from my OCaml bin directory (but it's all set-up by a script - the complexity is that you need to symlink the required runtime DLLs as well).

My point for OPAM really is that Cygwin already works (as it should), so it's not really much of a target for the roadmap!

> 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
> :-) ).

So you used MSYS to get the MinGW compiler, rather than Cygwin? I fail to see how that's really any more or less "natural" than using the Cygwin ones!


David