Re: [boost] Boost on Android

Subject: Re: [boost] Boost on Android
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-03-16 14:42:38

On 16 Mar 2015 at 20:13, Dmitry Moskalchuk wrote:

> > 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.
> 
> libc++ - it's LLVM libc++ from LLVM upstream with Google's
> modifications. In contrast with GNU libstdc++, it implemented even
> worse. It doesn't test features available on target platform on build
> stage, so Google's guys modified it much more than they did in GNU
> libstdc++. Unfortunately, all modifications lead to "get it built", not
> to "get it working". Thus, it's in "experimental" state in Google's NDK,
> and very unstable, crashing very frequently on real usage. Again, this
> happens because of bad Android libc implementation.

Ok, I did overegg the pudding. I really should have said "In my 
limited experience from Thread and AFIO, the libc++ STL is the least 
worst STL in the standard Android NDK". And I agree most of where the 
problems stem from is Google's poor quality libc. However I found 
that AFIO works well with libc++ on Android, and it is passing all 
unit tests quite nicely, and it didn't require much effort from me to 
make that happen. I had no chance with the other STLs as they're too 
outdated and AFIO is C++ 11 only.

> > 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.
> 
> Of course, this is choice of library maintainers. However, my personal
> opinion is that would be better to fix underlying layer (what we do in
> CrystaX NDK) than fixing Boost code itself.

I think we all agree that it is Google who is at fault here. They 
need to attach a STL expert to their Android NDK team for a year or 
two. This crappy C++ support makes a lot of hassle for anyone trying 
to use C++ on Android, and moreover this has been a big problem for 
*years* now. You really shouldn't have had to start CrystaX at all.

> > 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.
> 
> Supporting Android 5.0 is not enough practically.

Where I was going with that suggestion is that ALL Boost libraries 
support Android 5.0 with libc++ STL only. In other words, it becomes 
an officially recommended target.

That support ought to enormously ease your job in getting perfectly 
working ports for each API version because that config is the closest 
to the CrystaX one. Each library maintainer can of course choose to 
go further than just the base NDK.

> Please don't take it as aggressive style - I'm trying to avoid it 
but
> English is not my native language so it could look so. I'm just 
trying
> to explain why we started CrystaX NDK and why (IMHO) it's better 
choice
> than Google's one for Boost-on-Android.

I'm also coming from the perspective that Google need pressure to up 
their game. Personally speaking, I think they should write you an 
annual cheque for $50k and ship CrystaX as their official NDK. But I 
also recognise that someone's career in Google will suffer/resource 
problems/face saving/not on radar blah blah.

We need to get Google from where they are now to where Microsoft is 
now. Microsoft's compiler teams can make a very strong business case 
to their management for investment X, Y and Z because of A, B and C 
major libraries not working on their compiler. Microsoft then 
allocates resources, and all our lives improve in not having to head 
bash against MSVC as badly as before.

We need to instil a similar routine at Google. I'm sure the NDK teams 
would just love more resources to fix the C++ support, and I'm sure 
their management has decided it isn't worth the cost benefit. We need 
to tilt that analysis to make it worth the cost benefit.

One step to achieve that could be supporting only the very latest and 
greatest NDK release in Boost with a big fat statement about it being 
too much maintenance effort to go further (hint hint!). That same 
technique is used by countless C++ libraries to encourage MSVC to 
improve. I'm thinking it might work here too. The reason we shouldn't 
support CrystaX and not the Google NDK is because it makes it harder 
for the NDK team to pitch to their management because their 
management will view CrystaX as not the NDK, and therefore 
irrelevant.

I'm all for CrystaX support by the way. Just not without some support 
for the official Google NDK. Besides, as I mentioned I suspect if it 
supports Android 5.0 + libc++, the effort involved in making it work 
on CrystaX is probably trivial.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/