[GHC DevOps Group] DevOps: Next steps

[Ben Gamari]

"Boespflug, Mathieu" <m at tweag.io> writes:

> 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):
>
Some are shallow; some are less so. For instance, Template Haskell is
one of the larger issues at the moment. However, happily, it's possible
Angerman will be able to fix this for 8.4 (see D3608).

> - ./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/).
>
Thanks for pointing these out. Indeed having tickets for these would be
quite helpful when you get a chance. Also, do note that Moritz has been
doing work in this area. D4058 is somewhat relevant.

[1] https://phabricator.haskell.org/D4058

[...]

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

Manuel no doubt has something to add here, but for what it's worth I
have generally written off testing GHC on Android/iOS. Everything I have
heard of automated testing on these platforms make it sound absolutely
terrible.

Instead, I think it's significantly easier to just test a standard Linux
distribution running on ARM and AArch64. When I have done work on ARM in
the past this was how I tested (using any one of a number of inexpensive
development boards).

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20171011/fbbf03ec/attachment.sig>