Re: [boost] Boost on Android

Subject: Re: [boost] Boost on Android
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-03-19 08:04:53

On 16 Mar 2015 at 22:18, Dmitry Moskalchuk wrote:

> Even though I theoretically agreed with you, practically the best way to
> enforce Google to make improvements in their NDK is to provide
> alternative fork - that's what we do. This is what I did in 2009 and I
> suspect that otherwise we still wouldn't have C++ support in Google's
> NDK.

Your NDK preceded Google's C++ support?

> But current problems of Android is not just bad C++ support - it's
> much deeper. Android is just completely non-standard on native level and
> require huge efforts to do almost anything non-trivial with non-Java.
> Obviously, for Google it's not the priority at all. Of course, Google
> developers are very good;

Actually, not necessarily. I think their average is above average, as 
is the average of any tech multinational (they pay more, and have 
better managers and processes than smaller firms). But I've seen 
plenty of shockingly awful code come out of Google, same as any other 
tech multinational. One particular problem Google has which other 
companies don't as much are engineers who excel at looking and acting 
better than they actually are, something I would say about myself too 
incidentally :)

> but management is not aimed to support native
> development at all and the only way I see to change that is to provide
> alternative (working!) implementation of toolkit fixing all that birth
> traumas of Android. And even though enforcing Google to fix their NDK is
> strategically right thing to do, practically it could be years before
> they do that (if do at all).
> 
> If you insist on using Google's NDK for Android support in Boost, one
> way would be to support all Android versions with help of CrystaX NDK
> (which shouldn't require big effort from Boost developers since we
> provide standard-conforming behaviour) and only latest one (5.0 or 5.1)
> with Google's NDK, noting that explicitly in Boost documentation. This
> is what definitely will force Google's management to take situation into
> account and fix it; but this is harder for Boost developers since they
> will need support two toolkits (BTW, technically all compilers in
> CrystaX NDK define __CRYSTAX__ macro with value of 1, in addition to
> __ANDROID__).

Ok.

> > 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.
> 
> To make Boost libraries working with CrystaX NDK, no or minimal changes
> in Boost code required; to make them working with Google's NDK (even
> supporting only latest Android version) more changes in Boost will be
> required. If developers choose to support Google's NDK, please use "#if
> __ANDROID__ && !__CRYSTAX__" for conditional compilation to not break
> CrystaX NDK's build.

On reflection I believe I have softened my position on this, because 
I believe you are right that quality C++ support is far down the 
priority list for the Google NDK management. It therefore makes sense 
to make use of the community effort at Android workarounds i.e. 
CrystaX.

Ok, here's what I would suggest. You've already got the CrystaX 
results mounted at 
http://www.boost.org/development/tests/develop/developer/summary.html,
 so that's good, though you really ought to also be testing master 
branch on Android, or least especially after the 1.58 release. But 
what I would suggest is that you campaign for a "name and shame" of 
the top unit test failing libraries on master branch to be 
automatically posted once per month to boost-dev, where the ranking 
is scored by libraries consistently failing month after month. That 
would include all regression test failures, not just CrystaX.

As anyone examining that dashboard for master branch can see, there 
are libraries which fail month after month after month. Personally 
speaking, as this list knows, I'd have such libraries put onto a 
"pending deprecation and removal" list for 12 months, and then 
removed from the Boost distro. But perhaps a monthly name and shame 
might be enough to get some movement on fixing these regressions.

As the only example I have knowledge enough of to comment on, ASIO 
has been failing in the Boost regression suite for some time, but in 
fact it's all green in the standalone repo because Chris fixed all 
the failures that I know of after I reported them to him. So I 
suspect most of the regression matrix failures are simply maintainers 
not being aware, and a monthly reminder might help with that. It's 
unfortunate that ASIO 1.11 doesn't appear to be entering Boost 1.58, 
there are quite a few improvements coming including null_buffers 
being replaced!

Niall

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