Re-add rkward build to binary factory

[Thomas Friedrichsmeier]

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

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-windows/attachments/20190618/91428809/attachment.sig>