Does OPAM work on windows? #246
Comments
|
not yet, a 1.0 release targeting osx and linux is planned before end of november. After that, we'll focus on windows with a target release in Q1 2013. |
|
Any news on that front? If you need some help to beta-test OPAM under Windows, let me know! |
|
No news for now on, but that's the next big thing to do on my list! |
|
Actually, OPAM should now compile fine on Cygwin. However this is not tested at all so I suspect some things might break. Cygwin users, please feel free to open the specific issues you face. |
|
Can you provide steps to build OCaml + OPAM under Cygwin? Or even better, provide a binary installer as for Linux. I suspect that Windows users are even more likely to love that than Linux ones. Is your plan to support the Cygwin port only under Windows? In my opinion, this is the less useful one for Windows developers (as opposed to people wanting to quickly port existing Unix applications to Windows). |
|
As I said, this is not very well tested, but In a longer term, we indeed plan to have a proper support for windows (ie not based on Cygwin). The agenda for this is not totally clear though, as our first priority is to fully support the future OCaml Platform. |
|
This is a XP VM, with wodi32 installed. I began with a git clone. admin@testm2m ~/opam Executables will be installed in /usr/local/bin admin@testm2m ~/opam |
|
Some indications about what exactly ocp-build.boot is may help to provide help on this front. |
|
I've updated the bytecode blob of |
|
I had a look, but it is too complex for me :-( |
|
ocp-build.boot have been compiled on an unix system, so even if it's bytecode it can't run on a windows system. A windows bytecode doesn't contain unix_waitpid but win_waitpid. So I think it's impossible to bootstrap ocp-build that way on windows. (I used mingw port for testing it and ocp_build repository). |
|
@bobot we are cleaning the bytecode object to not include C call which are not used. So normally |
|
I have seen that you use ocp-bytecode but unix_waitpid appears in the bytecode of ocp-build because it is used inside the unix module (but not by function used by ocp-build). I tried to use remove-primitive.txt (If I understand well unix_waitpid is replaced by exit) and bootstrap work well. But then on windows that complain for unix_fork. Unfortunately fork is used in ocp-build but not available on windows: ./src/ocp-build/buildMisc.ml:148: match fork() with with the following remove-primitive.txt ./ocp-build -help can be run, but it print nothing (exit eearly) and the bootstrap doesn't work on linux : PS: can't the bootstrap be easier if ocp-build just generate a big script with all the commands to run? |
|
Installing the following packages worked fine under Cygwin: Cygwin packages: |
|
Interesting! By the way, there is a binary release of the external solver It would be interesting to know whether the external solver On Wed, Mar 26, 2014 at 10:16:29AM -0700, Ralf Vogler wrote:
Roberto Di Cosmo Professeur En delegation a l'INRIA FRANCE. Twitter: http://twitter.com/rdicosmoAttachments: http://www.gnu.org/philosophy/no-word-attachments.htmlOffice location: Bureau 3020 (3rd floor) Metro Bibliotheque Francois Mitterrand, ligne 14/RER CGPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3 |
|
Everything in %PATH% will also be found under Cygwin. I had no problems with calling Java and GraphViz. Use |
|
Thanks for the answer... then I expect aspcud to work properly on windows too :-) On Wed, Mar 26, 2014 at 10:44:05AM -0700, Ralf Vogler wrote:
Roberto Di Cosmo Professeur En delegation a l'INRIA FRANCE. Twitter: http://twitter.com/rdicosmoAttachments: http://www.gnu.org/philosophy/no-word-attachments.htmlOffice location: Bureau 3020 (3rd floor) Metro Bibliotheque Francois Mitterrand, ligne 14/RER CGPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3 |
|
Thanks a lot for reporting on this success :) |
|
I just tried to reproduce this success, and my experience is a mixed bag. Cygwin packages
The reason cmdliner fails to install seems to be related to dynlink. I will investigate the issue further. I will try again with opam 1.1 and reports about my experience. |
|
What was the error with |
|
IIRC, the build system does some |
|
It doesn't |
|
Thanks @dbuenzli . I will probably try again. This morning, I played again with the installation of OPAM on Windows, using the mingw32 toolchain. The compilation of OPAM and the ext-lib succeed, but the installation fails. Adding the opam binary to my path does not work either. $ opam My previous attempt was using the Cygwin port of OCaml, which, as far as I understand produces executables which depend on a DLL which is GPL'd. |
This uses the Appveyor CI service (similar to Travis) to build OPAM on Cygwin on Windows. It currently installs fine, but then runs into ocsigen/lwt#84 when installing Lwt. See ocaml#246
|
I've used the Appveyor Windows CI service (similar to Travis) to capture some of these build directions in a script to make it easier to keep working. See #1764 |
|
Are there plans to support native Windows ports in OPAM at some point? After fixing a few minor things in the build system, I managed to compile and install it with the MSVC port. Then "opam init" fails by trying call run "/bin/sh", which, of course, doesn't make sense for a native port. This is perhaps caused by OpamSystem.command_exists. Is there any point that I try to fix this one and continue with the test, or is it hopeless (e.g. because opam requires fork, signals, etc)? Generally speaking, it would be great to get some update on the plans for Windows support in opam (first note by @samoht on this ticket indicates a target in Q1 2013!). (Note that I would find it normal that opam requires a Cygwin environment -- the build system of many packages already do anyway -- but I don't see any deep reason to require opam itself to be a Cygwin executable, i.e. compiled with the Cygwin port of OCaml.) |
Should be on the 1.3 roadmap. See http://lists.ocaml.org/pipermail/opam-devel/2015-March/001002.html
@AltGr I'll point again to this code which has been tested on windows (also I notice that you eventually merged ocaml-opam/opam-depext#7 without fixing this, though I don't know if |
|
+1 getting this on chocolatey would be great |
|
Someone else maintained Opam for windows: http://fdopen.github.io/opam-repository-mingw/installation/ |
|
I'm packaging opam for cygwin, and I believe it will be accepted into the cygwin repo soon. I've tested that it work pretty nicely with the Cygwin OCaml package, but not so well with fdopen's opam repo. |
|
@andyli - fdopen's repository is intended for mingw/msvc ports, not the Cygwin ports of OCaml. Cygwin opam should be fine with the vanilla opam-repository and issues should be posted there. My roadmap for Cygwin/native opam does include being able to have Cygwin opam installing native compilers and vice versa, but my opinion remains that we shouldn't support it until proper cross-compilation arrives in OCaml (which might be around 4.07.0). |
|
IMO Cygwin is dead. As of Windows 10, Summer edition, developers can enable WSL and install Ubuntu on Windows, and invoke from CMD.EXE using BASH.EXE. Although not everything works, pretty much everything needed for a compiler or build system does, including gcc. The primary limitation is that Windows tools cannot operate on files in the Ubuntu file system. Both the Linux and Windows tools can operate on files in the (rest of the) Windows file system, however. Linux tools have to be invoked by BASH.EXE to enable WSL. However windows tools including CL.EXE (the C/C++ compiler) can be run there too. So Opam can be bootstrapped on Windows by installing it outside the Ubuntu filesystem and running it with BASH.EXE. It should work out of the box. Ocaml binaries built that way will be normal Linux binaries. However, with suitable packaging a Windows native Ocaml compiler can be built which will build code for Windows environment and link using MSVC. You can do this right now by hand, so it is just a matter of packaging to get opam to build Ocaml that way. In turn this means pure ocaml packages, or ones that use only Ocaml's Unix module subset available on Windows, will work out of the box using the Windows Ocaml. Only packages which build C code with gcc will fail: the resulting binaries can be built under Ubuntu but they aren't compatible with MSVC++. So those packages will have to be updated so the C building is adaptive and works on for CL.EXE. What this means is that you would build and install WIndows native Ocaml programs under Ubuntu on WIndows using Opam and tools which can invoke and use CL.EXE and Windows native ocaml. In short: MOST of the work is packaging, MOST of Opam's Unix specific stuff will just work out of the box. Supporting Cygwin and MingW type toolchains is a dead end. The main constraint is WIndows 10 Summer Edition is required. WSL is not available on WIndows 7. |
Why not? "Ubuntu file system" is just As for everything else I agree that WSL Opam managing native OCaml packages is the right way to go. |
IMO Windows is dead. Why not just install Linux instead of using WSL? (Ok, just kidding) To be serious, cygwin/mingw and WSL are very different projects and having very different goals. The cygwin/mingw toolchains create native Windows executables; WSL only run Linux executables. |
|
To be clear: we're going to continue to maintain Cygwin for some time. There is a large userbase depending on it for various purposes, and WSL is very new technology. |
|
"IMO Windows is dead. Why not just install Linux instead of using WSL? (Ok, just kidding)" Because all the games I like to play run on Windows.. :) Seriously, whilst Mingw etc create Windows executables, AFAIK they do not integrate with MSVC++ DLLs. MS has been a C++ shop for decades, indeed at one time they abandoned C altogether, refusing to upgrade their compiler to C11 (they change their minds I think). This problem isn't unique to Windows: clang and gcc C++ libraries aren't compatible either. Nor, in some details, are the compilers. I have used Cygwin in the past many times, and it was a life saver. But it was also very painful. On the other hand, being able to apt-get packages and just run stuff from Ubuntu out of the box was pure magic. My project's Linux build just worked first time. No X mind you, but you can install an X server for windows and then X client should work if configured. Anyhow the question here is how to get opam to work on Windows, and the right way is to rewrite the whole system from scratch in Ocaml using no C, and using only the subset of Unix module that work on both Windows and Unix. Shell dispatches then remain the primary difficulty. Its not clear if it is worth bothering, however. Will JaneSt libraries work on Windows? The thing is, software development is not about building executables, its about building libraries. Sigh. INRIA just dropped Bignum and I need opam to work on Windows so my clients can easily build my compiler which happens to use OCS Scheme which depends on Bignum. The replacement depends on third party LGPL without linking exemption libraries that the client needs to download not build. I hoped opam might automate this, but it doesn't work on Windows either. My system requires native MSVC Ocaml build because it requires MSVC anyhow. Building Ocaml is enough pain. I am wishing the compiler was written in C++ now. |
|
@skaller - no, they didn't change their minds, they support the only subset of C99 and C11 that is required by the C++ standard. The chances are higher to build a spaceship that can travel faster than light than the Microsoft build a fully-featured C compiler. On the other hand, Google realized that waiting is unproductive and invested the time of their engineers improving clang-cl, which is now able to compile Google Chrome. |
|
@alainfrisch you are right, thanks for pointing this out. Actually this not a real problem, you can always use symlinks to work around this: ln -s /mnt/c/Users/user/.opam ~/.opamThe real problem is to make |
|
@db4 - getting |
I would like to completely remove Cygwin dependency for native OCaml tools (even for build) if possible. To forgot about all these noacl in /etc/fstab, CYGWIN=winsymlinks:native etc. To have normal POSIX shell without Cygwin "features" that needs special workarounds. Looks like WSL is (almost?) complete Cygwin replacement, so why not? Back to the topic. Now I am trying to build the current opam from cygwin shell with make compiler OCAML_PORT=msvc
make lib-pkg
./configure --prefix c:/local/ocaml
make
make installThe last command fails with Do you have any idea what could be the problem? |
|
Removing the Cygwin dependency is perfectly possible (old branch here) - but it's not a panacea, you simply replace Cygwin-specific problems with WSL-specific ones (but it's much faster, so I think it's certainly worth supporting, but Cygwin will remain the official OCaml build system for some considerable time). Regarding the build failure, you need at least 5255239 from #3260. But the opam you'll compile at that point won't init... |
|
Feel free to open an issue on the msvs-tools tracker for operation from within WSL. I'm happy to work on that, I just don't have time right now. |
Is there any commint/branch that just works and is better than Andreas Hauptmann win32 build (OCaml for Windows)? With his build I have I don't know if it could be ignored or it really cannot use Or maybe cygwin OPAM build is still recommended to manage native Win32 OCaml packages? |
|
To answer the original question:
Yes, it does 🥳 |
|
I can't understate how much of an achievement this is... My deepest regards to the team. Wanted to react with 🤯 but Github doesn't have that option :) |
|
Thank you so much guys! This is useful! I hate windows but this is useful! |
and others
I really don't know.
The text was updated successfully, but these errors were encountered: