<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Jan 11, 2019 at 8:52 AM Volker Krause <<a href="mailto:vkrause@kde.org" target="_blank">vkrause@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Friday, 11 January 2019 02:22:17 CET Aleix Pol wrote:<br>
> On Thu, Jan 10, 2019 at 9:34 PM Volker Krause <<a href="mailto:vkrause@kde.org" target="_blank">vkrause@kde.org</a>> wrote:<br>
> > Hi,<br>
> > <br>
> > with NDK 17 GCC got deprecated, with 18 (from Sep 2018) it even got<br>
> > entirely<br>
> > removed, and with it the corresponding C++ STL libs. And the current Qt<br>
> > SDK<br>
> > (5.12) only ships with clang-based binaries. Do we still want to support<br>
> > GCC-<br>
> > based NDKs? If so for how long? If no, does it make sense to make a hard<br>
> > cut<br>
> > now, and switch everything to the newer NDKs and the Clang-based<br>
> > toolchain?<br>
> > <br>
> > I'm wondering as we are hitting limits with the wide NDK and SDK range we<br>
> > currently try to support, e.g.<br>
> > <a href="https://phabricator.kde.org/R1007:3c86b3900aafa374389dee74ec83ae17488d521d" rel="noreferrer" target="_blank">https://phabricator.kde.org/R1007:3c86b3900aafa374389dee74ec83ae17488d521d</a><br>
> > is<br>
> > needed to build with NDK 18/SDK 28 and Qt 5.12, but it breaks binary<br>
> > factory<br>
> > and any other older setup.<br>
> > <br>
> > Note that this is only about the compile-time requirements, this has no<br>
> > effect<br>
> > on still supporting older API levels for the resulting apps at runtime,<br>
> > that<br>
> > we definitely want to keep.<br>
> > <br>
> > Regards,<br>
> > Volker<br>
> <br>
> I'd say it doesn't make a whole lot of sense to support anything other than<br>
> r18.<br>
<br>
I agree, certainly for everything we distribute. And with Google pushing these <br>
updates I doubt there is a relevant external user base that is using KDE <br>
building blocks and insists on ancient NDKs.<br>
<br>
> I've been working on it on this patch (okay, it's been sitting for a while,<br>
> but I can see to get it applied).<br>
> <a href="https://phabricator.kde.org/D18173" rel="noreferrer" target="_blank">https://phabricator.kde.org/D18173</a><br>
<br>
Nice! Looks good to me as far as I can follow Docker stuff. I can at least <br>
confirm for the framework subset used by KDE Itinerary that Clang, NDK 18 and <br>
Qt 5.12 work just fine. The previous OpenSSL build also still works here, but <br>
I haven't checked if Qt 5.12 might also accept a newer version meanwhile.<br>
<br>
Regards,<br>
Volker<br>
<br>
> We can keep a legacy image for Qt 5.11 with gcc and this one as official<br>
> for Qt 5.12 while we transition.<br>
> <br>
> Aleix<br>
<br></blockquote><div><br></div><div><div style="font-size:small" class="gmail_default"><div class="gmail_default" style="font-size:small">You can try it with:<br></div><div class="gmail_default" style="font-size:small">docker pull apol/asdk:clang<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Regarding SSL, since there we're compiling Qt, we don't have to do all the guesswork of what version "they" may have built it against.</div><div class="gmail_default" style="font-size:small">Or at least that was my reasoning.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I'll try to send you an itinerary build with it if you want to test. Or you generate it just like with kdeorg/android-sdk.</div><div class="gmail_default" style="font-size:small">Aleix<br></div></div><br></div><div> </div></div></div>