[opam-devel] [Caml-list] Thoughts on targeting windows

[Anil Madhavapeddy]

(CCing opam-devel with David's permission)

This is a good question -- I also have the same problem of not being able to quickly check what's happening on OPAM and Windows, since it isn't my primary development platform.

I think that Appveyor looks very promising as a way to keep Windows tested, once it has initially passed. For example, see the Ctypes Windows patch stream: https://github.com/ocamllabs/ocaml-ctypes/pull/191

We could just keep extending the Appveyor config file that's in the OPAM repository right now and add known-good packages to the installations that it attempts.  Your Windows/bash shell scripts would be a good start, and we could get in touch with the WODI maintainer to find out if they are interested in merging some of those patches into the OPAM repository as well.

-anil

> On 6 Oct 2014, at 12:27, David Allsopp <dra-news at metastack.com> wrote:
> 
> I hope the off-list reply is OK: as a related aside, is there an easy way to monitor the status of OPAM on Windows (i.e. a particular user's fork, long running pull requests, etc.)?
> 
> I'm not blessed with a vast amount of time (who of us is!) but I'm thinking that next time I update my OCaml-on-Windows installation (which usually involves a lot of patching - but I'd really like to migrate from 4.01 to 4.02), the energy would be better poured into OPAM, but I don't want to duplicate others' efforts by mistake.
> 
> As far as I can tell, the infrastructure of OPAM should be perfect for Windows use because it provides a better way to maintain the local patches often required for Windows building - at the moment, I have a "clever" mix of a Windows/Bash shell script which maintains the patches, dependency resolution and build instructions for the 35 packages I use.
> 
> 
> David
> 
>> -----Original Message-----
>> From: Anil Madhavapeddy [mailto:anil at recoil.org]
>> Sent: 05 October 2014 23:15
>> To: David Allsopp
>> Cc: caml-list at inria.fr
>> Subject: Re: [Caml-list] Thoughts on targeting windows
>> 
>> On 9 Jun 2014, at 16:23, David Allsopp <dra-news at metastack.com> wrote:
>> 
>>> William wrote:
>>>> we are considering using OCaml for a rather large project, the bulk
>>>> of which will be networking and encryption. OCaml seems to meet our
>>>> needs with one exception: we'd like to target windows (as well as
>>>> linux & mac) and we got the impression that this would be complicated
>>>> -- we gathered that neither jane street's Core nor OPAM are windows
>>>> compatible.
>>> 
>>> It's more complicated than Linux (& Mac), but not overly so.
>>> 
>>>> Would still recommend using OCaml? Are there workarounds, or other
>>>> libraries that would replace Core?
>>> 
>>> I believe Core_kernel aims to be the platform-neutral parts of core?
>> There are other Jane Street libs which compile just fine on Windows.
>> Batteries, as others have noted, works out of the box. Usually, I find
>> that the biggest problem in third party libs is in build systems (becoming
>> less so with Oasis, OCamlbuild and so on) making naïve decisions about
>> Windows but that doesn't usually take much patching.
>>> 
>>> Most of what I do is Windows-oriented, but some of what I've done is
>> Windows and Linux. My experience is that it's important to keep Windows in
>> the picture early on to avoid pain later - so ensure that daily builds are
>> working on Windows or perhaps that one of your developers is always
>> working on Windows or something... that should avoid accidentally
>> selecting a Unix-only library and only realising that a painfully long way
>> down the road (or that the library you thought was cross-platform contains
>> an assert false for the function you need when running on Windows!). If
>> you write something which works on Windows in OCaml it will probably
>> translate with little pain to Linux but the reverse isn't necessarily
>> true.
>> 
>> At a recent compiler hacking session in Cambridge, Don Syme pointed out a
>> great Travis-like service for running regular Windows builds called
>> Appveyor(.com).  In order to get more familiar with the Windows toolchain,
>> I ported some of Thomas Braibant's instructions for compiling OPAM on
>> Windows using it here:
>> 
>> Cygwin scripts: https://github.com/ocaml/opam/blob/master/appveyor.yml
>> Build output:   https://ci.appveyor.com/project/avsm/opam/build/1.0.38
>> 
>> Appveyor can be used much like Travis and build every Git checkin on
>> Windows, except that they unfortunately overwrite each other's status
>> flags (the green tick or red cross against each commit), so they cannot be
>> simultaneously used on one GitHub repository right now.  I contacted
>> GitHub support and they indicated that they are adding support for
>> multiple CI tools into the UI, but do not have a time estimate for when
>> that would be ready.
>> 
>> In the meanwhile though, I hope Appveyor comes in useful for anyone
>> wanting to automate Windows testing via a free hosted service.  Pull
>> requests to improve OPAM's Appveyor scripts in this regard (for MinGW or
>> Cygwin or ideally testing them both) would be welcome.
>> 
>> best,
>> Anil
>