Subject: Re: [boost] Boost on Android
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-03-16 12:17:56
On 16 Mar 2015 at 17:41, Dmitry Moskalchuk wrote:
> I hope I did not violated rules of this mailing list because my message
> is directly related to the Boost development. We just want to make both
> CrystaX NDK and Boost better.
Not to diminish the fine work that CrystaX does, but I want to
emphasise to the community that the CrystaX NDK != the Android NDK.
Configuring build support specific to the Android NDK is
straightforward if not well documented: if necessary to your Jamfile
you add config for target-os=android as this is a cross compilation
scenario. Similarly, when building Boost to target Android you pass
target-os=android to b2.
I'll also add some of my own experiences as I formalised the port of
Thread to Android, plus AFIO v1.3 is now regularly CI tested on
Android. Firstly, the STL default configured by the Android NDK is
woefully defective, however the good news is that the recent NDKs can
be asked to use libc++ and that's a very recent edition of libc++, so
you get excellent C++ 14 STL support. Secondly, the NDK lets you
choose between GCC 4.6, 4.8 and clang 3.5, the latter two obviously
have much superior C++ 11 support, but the clang port in particular
is a bit ropey. Thirdly, Boost when compiled with -std=c++11 or later
with the wrong combination of STL headers on the NDK has weird
outcomes - basically build failures. AFIO fails to build on the NDK
if any Boost code comes into play, yet compiles perfectly when built
standalone, however Thread is fine being built in C++03, C++11 and
C++14 builds. Go figure I guess.
My suggestion to the community is to try and target as a minimum 100%
green for Android 5.0 only with the libc++ STL only. Maintainers may
choose to exceed that of course. If you target that one single target
and keep it all green, that makes the life of CrystaX much easier
because effectively speaking what he's done is port newer STLs etc to
the older API versions, so really all you need to maintain is the
occasional #ifdef __ANDROID__ to work around Android's weird libc and
library config and in theory at least, it ought to be good from
there.
I do personally think being asked to keep build and unit tests all
green for Androids before 5.0 when the C++ toolset is crap is asking
too much of Boost. There are at least twenty different API versions,
all of which can be built using multiple NDK versions and configs.
Choosing one single sane API version (5.0 minimum) and toolset
(libc++ STL only) helps encourage Google to ship non-braindamaged C++
tooling set to default in their NDK, which is long overdue.
Any my thanks to CrystaX for all their effort in their NDK fork. It's
hugely appreciated by anyone needing to deal with getting C++ working
on Android, believe me.
Niall
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/