[Caml-list] Thoughts on targeting windows

[Caml-list] Thoughts on targeting windows

[William]

[-- Attachment #1: Type: text/plain, Size: 487 bytes --]

Hi all,

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.

Would still recommend using OCaml? Are there workarounds, or other
libraries that would replace Core?

All the best,
William

[-- Attachment #2: Type: text/html, Size: 556 bytes --]

Re: [Caml-list] Thoughts on targeting windows

[Virgile Prevosto]

Hello,

2014-06-09 10:56 GMT+02:00 William <sirrobin2318@gmail.com>:
> 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.

regarding OCaml package management under Windows, you should have a
look at wodi:
http://wodi.forge.ocamlcore.org/
The package page lists core_kernel, batteries and extlib, but as I use
none of those I can't tell how well they work on Windows.

Best regards,
-- 
E tutto per oggi, a la prossima volta
Virgile

Re: [Caml-list] Thoughts on targeting windows

[John Whitington]

Hi,

William wrote:
> Hi all,
>
> 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.
>
> Would still recommend using OCaml? Are there workarounds, or other
> libraries that would replace Core?

Here is the Windows installer:

http://protz.github.io/ocaml-installer/

This also installs 'ocamlfind', which means that you can download source 
packages for libraries you're interested in, compile them, install them 
and use them relatively easily. Not as convenient as OPAM, of course.

Here is a library for cryptography:

https://forge.ocamlcore.org/projects/cryptokit/

Here is a library for concurrency which runs on Windows:

http://ocsigen.org/lwt/

Here is a different Standard Library replacement/augmentation:

https://github.com/ocaml-batteries-team/batteries-included

(The software I build for Windows, whilst complex in terms of what it 
does, is just a single statically linked executable which reads a file, 
processes it and writes a file, so I can't tell you anything about 
networking under Windows.)

Thanks,

-- 
John Whitington
Director, Coherent Graphics Ltd
http://www.coherentpdf.com/

Re: [Caml-list] Thoughts on targeting windows

[Yotam Barnoy]

[-- Attachment #1: Type: text/plain, Size: 2066 bytes --]

Speaking of which, are there any updates on the Windows situation with
regard to opam and Core? Specifically with regard to Core, I find it odd
that Ocaml's most popular (and well-written) book doesn't support the most
popular OS in the world.

-Yotam


On Mon, Jun 9, 2014 at 5:16 AM, John Whitington <john@coherentgraphics.co.uk
> wrote:

> Hi,
>
>
> William wrote:
>
>> Hi all,
>>
>> 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.
>>
>> Would still recommend using OCaml? Are there workarounds, or other
>> libraries that would replace Core?
>>
>
> Here is the Windows installer:
>
> http://protz.github.io/ocaml-installer/
>
> This also installs 'ocamlfind', which means that you can download source
> packages for libraries you're interested in, compile them, install them and
> use them relatively easily. Not as convenient as OPAM, of course.
>
> Here is a library for cryptography:
>
> https://forge.ocamlcore.org/projects/cryptokit/
>
> Here is a library for concurrency which runs on Windows:
>
> http://ocsigen.org/lwt/
>
> Here is a different Standard Library replacement/augmentation:
>
> https://github.com/ocaml-batteries-team/batteries-included
>
> (The software I build for Windows, whilst complex in terms of what it
> does, is just a single statically linked executable which reads a file,
> processes it and writes a file, so I can't tell you anything about
> networking under Windows.)
>
> Thanks,
>
> --
> John Whitington
> Director, Coherent Graphics Ltd
> http://www.coherentpdf.com/
>
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 3451 bytes --]

Re: [Caml-list] Thoughts on targeting windows

[Matthieu Dubuget]

I may be wrong… but the last time I read this problem commented,
the comment was something like… Hum. Just use a virtual machine
and wait for a nice cross-compilation system in order to target windows.

Maybe I misunderstood?

Salutations

-- 
Matthieu Dubuget

RE: [Caml-list] Thoughts on targeting windows

[David Allsopp]

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. 

While OPAM is great, I personally find that downloading and compiling a library, even by hand, represents an insignificant amount of time compared with reading its documentation, evaluating its samples and so on in the overall process of working out whether I want to use a component... but apparently the pain of not having a package manager really, really, really hurts people coming from the Unix world ;o)

HTH,


David

Re: [Caml-list] Thoughts on targeting windows

[Yaron Minsky]

Core_kernel is pure OCaml, and so should work fine on Windows (and Javascript!)

y

On Mon, Jun 9, 2014 at 11:23 AM, David Allsopp <dra-news@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.
>
> While OPAM is great, I personally find that downloading and compiling a library, even by hand, represents an insignificant amount of time compared with reading its documentation, evaluating its samples and so on in the overall process of working out whether I want to use a component... but apparently the pain of not having a package manager really, really, really hurts people coming from the Unix world ;o)
>
> HTH,
>
>
> David
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Thoughts on targeting windows

[Sebastien Mondet]

[-- Attachment #1: Type: text/plain, Size: 3164 bytes --]

On Mon, Jun 9, 2014 at 2:59 PM, Yaron Minsky <yminsky@janestreet.com> wrote:

> Core_kernel is pure OCaml, and so should work fine on Windows (and
> Javascript!)
>
>
Actually some dependencies of core_kernel have C code, like bin_prot:
https://github.com/janestreet/bin_prot/blob/master/lib/blit_stubs.c




> y
>
> On Mon, Jun 9, 2014 at 11:23 AM, David Allsopp <dra-news@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.
> >
> > While OPAM is great, I personally find that downloading and compiling a
> library, even by hand, represents an insignificant amount of time compared
> with reading its documentation, evaluating its samples and so on in the
> overall process of working out whether I want to use a component... but
> apparently the pain of not having a package manager really, really, really
> hurts people coming from the Unix world ;o)
> >
> > HTH,
> >
> >
> > David
> >
> > --
> > Caml-list mailing list.  Subscription management and archives:
> > https://sympa.inria.fr/sympa/arc/caml-list
> > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> > Bug reports: http://caml.inria.fr/bin/caml-bugs
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 4555 bytes --]

Re: [Caml-list] Thoughts on targeting windows

[Yaron Minsky]

Indeed! I forgot about that last little bit.  We killed most of the C,
but there's a bit left.  That said, those should be pretty portable,
and can (and have been) stubbed out so it can work in a Javascript
context.

y

On Mon, Jun 9, 2014 at 3:34 PM, Sebastien Mondet
<sebastien.mondet@gmail.com> wrote:
>
>
>
> On Mon, Jun 9, 2014 at 2:59 PM, Yaron Minsky <yminsky@janestreet.com> wrote:
>>
>> Core_kernel is pure OCaml, and so should work fine on Windows (and
>> Javascript!)
>>
>
> Actually some dependencies of core_kernel have C code, like bin_prot:
> https://github.com/janestreet/bin_prot/blob/master/lib/blit_stubs.c
>
>
>
>>
>> y
>>
>> On Mon, Jun 9, 2014 at 11:23 AM, David Allsopp <dra-news@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.
>> >
>> > While OPAM is great, I personally find that downloading and compiling a
>> > library, even by hand, represents an insignificant amount of time compared
>> > with reading its documentation, evaluating its samples and so on in the
>> > overall process of working out whether I want to use a component... but
>> > apparently the pain of not having a package manager really, really, really
>> > hurts people coming from the Unix world ;o)
>> >
>> > HTH,
>> >
>> >
>> > David
>> >
>> > --
>> > Caml-list mailing list.  Subscription management and archives:
>> > https://sympa.inria.fr/sympa/arc/caml-list
>> > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> > Bug reports: http://caml.inria.fr/bin/caml-bugs
>>
>> --
>> Caml-list mailing list.  Subscription management and archives:
>> https://sympa.inria.fr/sympa/arc/caml-list
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

Re: [Caml-list] Thoughts on targeting windows

[Thomas Gazagnaire]

> Indeed! I forgot about that last little bit.  We killed most of the C,
> but there's a bit left.  That said, those should be pretty portable,
> and can (and have been) stubbed out so it can work in a Javascript
> context.

Indeed, little changes are needed to compile core_kernel to javascript. See https://github.com/janestreet/core_kernel/pull/8

Thomas

> 
> y
> 
> On Mon, Jun 9, 2014 at 3:34 PM, Sebastien Mondet
> <sebastien.mondet@gmail.com> wrote:
>> 
>> 
>> 
>> On Mon, Jun 9, 2014 at 2:59 PM, Yaron Minsky <yminsky@janestreet.com> wrote:
>>> 
>>> Core_kernel is pure OCaml, and so should work fine on Windows (and
>>> Javascript!)
>>> 
>> 
>> Actually some dependencies of core_kernel have C code, like bin_prot:
>> https://github.com/janestreet/bin_prot/blob/master/lib/blit_stubs.c
>> 
>> 
>> 
>>> 
>>> y
>>> 
>>> On Mon, Jun 9, 2014 at 11:23 AM, David Allsopp <dra-news@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.
>>>> 
>>>> While OPAM is great, I personally find that downloading and compiling a
>>>> library, even by hand, represents an insignificant amount of time compared
>>>> with reading its documentation, evaluating its samples and so on in the
>>>> overall process of working out whether I want to use a component... but
>>>> apparently the pain of not having a package manager really, really, really
>>>> hurts people coming from the Unix world ;o)
>>>> 
>>>> HTH,
>>>> 
>>>> 
>>>> David
>>>> 
>>>> --
>>>> Caml-list mailing list.  Subscription management and archives:
>>>> https://sympa.inria.fr/sympa/arc/caml-list
>>>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>>>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>>> 
>>> --
>>> Caml-list mailing list.  Subscription management and archives:
>>> https://sympa.inria.fr/sympa/arc/caml-list
>>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>> 
>> 
> 
> -- 
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Thoughts on targeting windows

[Anil Madhavapeddy]

On 9 Jun 2014, at 16:23, David Allsopp <dra-news@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

Re: [Caml-list] Thoughts on targeting windows

[Jeremy Yallop]

On 5 October 2014 23:14, Anil Madhavapeddy <anil@recoil.org> wrote:
> 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.

I recently learnt of a solution to this issue: there's a third party
application which makes it possible to display both Travis and
AppVeyor build status flags on each commit:

   http://help.appveyor.com/discussions/kb/4-show-multiple-statuses-in-github-pull-requests

For example, on the following pull request

   https://github.com/yallop/ci-testing/pull/1

the status currently reads

   "Waiting to hear about 7e7a1ac — The Travis CI build passed /
Waiting for AppVeyor build to complete"

and links to a page with links to both the Travis and AppVeyor builds:

   http://github-multi-status.herokuapp.com/view?owner=yallop&repo=ci-testing&sha=7e7a1ac397a6eb3a5dc8937db4ea875617790280

Re: [Caml-list] Thoughts on targeting windows

[Anil Madhavapeddy]

On 9 Oct 2014, at 10:33, Jeremy Yallop <yallop@gmail.com> wrote:
> 
> On 5 October 2014 23:14, Anil Madhavapeddy <anil@recoil.org> wrote:
>> 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.
> 
> I recently learnt of a solution to this issue: there's a third party
> application which makes it possible to display both Travis and
> AppVeyor build status flags on each commit:
> 
>   http://help.appveyor.com/discussions/kb/4-show-multiple-statuses-in-github-pull-requests

An update: GitHub now supports multiple status updates, so any projects
that wish to use Appveyor (Windows) and Travis (Linux/OSX) simultaneously
can now do so: 

https://github.com/blog/1935-see-results-from-all-pull-request-status-checks

-anil