Re-add rkward build to binary factory

[Ben Cooksley]

On Wed, Jun 19, 2019 at 1:55 AM Thomas Friedrichsmeier
<thomas.friedrichsmeier at ruhr-uni-bochum.de> wrote:
>
> On Tue, 18 Jun 2019 23:34:06 +1200
> Ben Cooksley <bcooksley at kde.org> wrote:
> > Sorry about the MacOS removal. That was unintentional and an oversight
> > on my part when I was enabled the MSVC Windows builds.
> > Turns out the Python YAML parser is very tolerant of invalid YAML.
> >
> > It's fixed now and the job should be restored shortly.
>
> Ok, thanks for bringing it back!
>
> Now that qtwebkit seems to be building for MinGW, again, could you also
> bring back our MinGW build? As I wrote, it's our safer option, for the
> time being (and in fact the MSVC build seems to suffer from at least
> one specific crash while using the R API - haven't had the time to
> investigate that one, in detail, yet).

I've re-enabled that one now.

>
> As for a long-term plan, one idea I had is along the following lines,
> although I'm not sure whether / how this will be possible with craft:
>
> We're building two separate processes for RKWard, already. Only one
> needs to be linked against R, and thus using MinGW. The other process
> should be totally fine with MSVC (and could then be ported to
> QWebEngine).
>
> Splitting the build into two parts should not be too difficult. So, in
> theory, we could build the backend using MinGW, and the frontend
> using MSVC. But then we'd have to bring them both together, somehow.
> Any pointers for me one this, or does it seem way out of whack to even
> try?
>
> > With regards to why the RKWard job regressed, this is a limitation of
> > R.framework on MacOS it would seem. In the past few months we've
> > switched to using a Binary Cache, meaning builds on the Binary Factory
> > are now faster and can be more reliably reproduced outside of the
> > single Binary Factory system. It also supports us having a second
> > machine in the future should we so wish to do so.
> >
> > Unfortuantely it does mean that path rewriting must now work fully,
> > otherwise stale paths will be referenced (and cause failures). I'm not
> > sure why R.framework is mentioning a system wide location directly
> > like that though.
> >
> > Chances are the correct solution for this will be to rewrite paths
> > within R.framework as part of it's unpacking process - once that is
> > sorted.
>
> Ok, I hope to figure out that one, soon. But Windows, first...
>
> Regards
> Thomas

Cheers,
Ben