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/