[GHC DevOps Group] DevOps: Next steps

[Boespflug, Mathieu]

Hi Ben,

On 11 October 2017 at 17:01, Ben Gamari <ben at well-typed.com> wrote:
>
> [...]
>
> Well, as GHC is not GCC, GHC is also not Rust. Rust has the advantage of
> having a strong cross-compilation story, and a testsuite which was
> designed to make this usage easy. GHC is behind rust in both of these
> areas.

Arguably so, yes. My experience is that there are more or less shallow
bugs that stand in the way of a good cross compilation story, but
nothing we can't address in due time. My experiments with FreeBSD this
weekend uncovered the following as-yet-unresolved issues (which I do
still need to open tickets for):

- ./validate --build-only does execute some some command compiled for
the target, not the host. And therefore fails. This happens very late
in the build process.
- make binary-dist works, but for some reason the RPATH's for
libHS*.so libraries don't get set the same as they do when being built
natively (symptom: make install fails when running commands that
dynamically load such libraries before they go to /usr/local/lib/).

> Yesterday I discussed this with two core members of the Rust
> infrastructure team; who explicitly said that (paraphrasing, albeit
> closely, as I didn't ask permission to quote him at the time),
>
>  * making CI under qemu fast is nontrivial; their testing strategy of
>    running the compiler on the host and running only the tests
>    themselves on the target is critical to making the approach scale
>
>  * when issues occur, debugging issues inside the emulator has proven to
>    be quite difficult

It's great to have first hand experience reports from the Rust folks.
Thanks for having reached out to them already!

I can very much believe that building a cross compiler first on the
host saves quite a bit of time.

> At this point I'm fairly close to agreeing with you that CircleCI is the
> right path forward. My primary reservation continues to be non-Linux
> platforms.

Cool. :) I suggest pushing forward with drafting the list of
requirements first. To make sure we identify anything important that
may or not have come up in the discussion so far. And then Manuel will
want to see a proposal put forth to the group. Given this current
landscape,

- there are 3 major desktop OS'es (Windows, macOS, Linux)
- there are 2 major mobile OS'es (iOS, Android),

I think we'll want something that works for the 3 major desktop
platforms now (aka the current "Tier 1"). And maybe later consider how
to best support the major mobile platforms, or indeed other desktop
platforms if the maintainership resources are there.

As Facundo mentions - in reality even the choice of how we run tests
for the mobile platforms is independent of the CI driver. Remote
drones are also *possible* using hosted CI services (at some
complexity cost that might not outweigh those of straight up
emulation). We've done that before with AWS drones.

Best,

Mathieu