Supported NDK versions

[Aleix Pol]

On Fri, Jan 11, 2019 at 8:52 AM Volker Krause <vkrause at kde.org> wrote:

> On Friday, 11 January 2019 02:22:17 CET Aleix Pol wrote:
> > On Thu, Jan 10, 2019 at 9:34 PM Volker Krause <vkrause at kde.org> wrote:
> > > Hi,
> > >
> > > with NDK 17 GCC got deprecated, with 18 (from Sep 2018) it even got
> > > entirely
> > > removed, and with it the corresponding C++ STL libs. And the current Qt
> > > SDK
> > > (5.12) only ships with clang-based binaries. Do we still want to
> support
> > > GCC-
> > > based NDKs? If so for how long? If no, does it make sense to make a
> hard
> > > cut
> > > now, and switch everything to the newer NDKs and the Clang-based
> > > toolchain?
> > >
> > > I'm wondering as we are hitting limits with the wide NDK and SDK range
> we
> > > currently try to support, e.g.
> > >
> https://phabricator.kde.org/R1007:3c86b3900aafa374389dee74ec83ae17488d521d
> > > is
> > > needed to build with NDK 18/SDK 28 and Qt 5.12, but it breaks binary
> > > factory
> > > and any other older setup.
> > >
> > > Note that this is only about the compile-time requirements, this has no
> > > effect
> > > on still supporting older API levels for the resulting apps at runtime,
> > > that
> > > we definitely want to keep.
> > >
> > > Regards,
> > > Volker
> >
> > I'd say it doesn't make a whole lot of sense to support anything other
> than
> > r18.
>
> I agree, certainly for everything we distribute. And with Google pushing
> these
> updates I doubt there is a relevant external user base that is using KDE
> building blocks and insists on ancient NDKs.
>
> > I've been working on it on this patch (okay, it's been sitting for a
> while,
> > but I can see to get it applied).
> > https://phabricator.kde.org/D18173
>
> Nice! Looks good to me as far as I can follow Docker stuff. I can at least
> confirm for the framework subset used by KDE Itinerary that Clang, NDK 18
> and
> Qt 5.12 work just fine. The previous OpenSSL build also still works here,
> but
> I haven't checked if Qt 5.12 might also accept a newer version meanwhile.
>
> Regards,
> Volker
>
> > We can keep a legacy image for Qt 5.11 with gcc and this one as official
> > for Qt 5.12 while we transition.
> >
> > Aleix
>
>
You can try it with:
docker pull apol/asdk:clang

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.
Or at least that was my reasoning.

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.
Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-android/attachments/20190112/f28bc4e9/attachment.html>