On Wed, Jun 19, 2019 at 1:55 AM Thomas Friedrichsmeier <thomas.friedrichsme...@ruhr-uni-bochum.de> wrote: > > On Tue, 18 Jun 2019 23:34:06 +1200 > Ben Cooksley <bcooks...@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
