From kde-windows  Tue Jun 18 13:55:12 2019
From: Thomas Friedrichsmeier <thomas.friedrichsmeier () ruhr-uni-bochum ! de>
Date: Tue, 18 Jun 2019 13:55:12 +0000
To: kde-windows
Subject: Re: Re-add rkward build to binary factory
Message-Id: <20190618155512.5f0df56a () edge>
X-MARC-Message: https://marc.info/?l=kde-windows&m=156086613416999
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--Sig_/J1LAy90qJVpcQc2Oo/yR5/f"

--Sig_/J1LAy90qJVpcQc2Oo/yR5/f
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Tue, 18 Jun 2019 23:34:06 +1200
Ben Cooksley <bcooksley@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.
>=20
> 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).=20

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?
=20
> 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.
>=20
> 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.
>=20
> 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

--Sig_/J1LAy90qJVpcQc2Oo/yR5/f
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEby3AwIMM6jiQ/yLPORWR3xhYy7YFAl0I7UAACgkQORWR3xhY
y7Z59RAAh/5ahHiHyw0/8sjmxYy+DQU1qz6qYRPm0SEFzGDOIGAjiY/CZFT4BmTR
+SIGCk9zR8IuiaBOI5pl5VTSLPAWdrdZSzjDObyE2cp/WR9lc5fk2PWZayn2ZNXw
tXWSoqlX0vV6zlwTJE1n6t/+TUy8p0lwy+s09VSZTYTWiF2stGE5zKYHUXj6bezQ
jVrexLY8sabPmrkk6OSMD4Bu+Dl8tQzEx4WLv/MAboZYjdY/xmIW0x31S59mbv06
dv2Ps+qQtFvOg1lXEBbmGZ702r3HqyARSLphPensZfpfT/0LCMka7cqs+LTu6/6c
hfKNLlUzhTOKy8qrgf3UT8v9J1STAS6vkJkQZFleGcMHzZ4Sm/rFya1aBY6Wb0lE
RMBsZz/lH6dnwt8HqQxKTXX5IkEocg1iHvCK7QzpAcxRbUOLo/AQg2xxqG3/wyfQ
tJZtuCiBlMXGfGD0qe7Dh/p9lVuUo1wseDTaPzrwkjb7ukv9a9LFQAwQUl6ykNZx
QXx27YuMehmdcMBABXYCmycxtILL7XoDCXo8cfMyctvjjfenDK22cNmq57h3yUJy
qOm7SJSeIzSEhm6xpjMa9nmRw+fPC4JMaCxNFAl2tVUCdMGwO3jRF0zHZ4IIyfn+
cOoZyBw1e2gTHQpFzWMYUsvRYZbRN/HJ67wrj7ktKAWMXzx2nfA=
=DPIC
-----END PGP SIGNATURE-----

--Sig_/J1LAy90qJVpcQc2Oo/yR5/f--