Supported NDK versions

[Volker Krause]

On Saturday, 12 January 2019 03:57:40 CET Aleix Pol wrote:
> 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.

Thanks, just tested your build, works fine here :)

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-android/attachments/20190114/563a0637/attachment.sig>