Hi all, As someone of you already know, we've started regular regression testing of Boost on Android. After some (bit longer than I expected) time of debugging, we finally made it working in automatic mode so you can see our results of Boost testing on http://www.boost.org/development/tests/develop/developer/summary.html. We also automatically publish Android-only testing results on https://boost.crystax.net/master/developer/summary.html and https://boost.crystax.net/develop/developer/summary.html. Currently, we have numerous of fails. Some of them are bugs of Boost libraries, some - bugs of CrystaX NDK. We're strongly aim to continue support Boost on Android and fix our NDK to make Android as POSIX-conforming as possible; however, it's not easy to review all fails and distinguish NDK bugs from Boost bugs. So we're asking Boost libraries authors to start looking on Android regression testing results and file tickets to our tracker (https://tracker.crystax.net/projects/ndk) if it become clear that root of fail is bug of CrystaX NDK. CrystaX NDK is open-source project started as my personal project in 2009 to add C++ support to the Google's Android NDK (Google published first Android NDK release in 2009, and there was no support of C++ at all). My patches were published immediately but Google have added the same level of C++ support two years after first CrystaX NDK release, being constantly requested within two years to do that by Android developers community. To that time CrystaX NDK was much more than just "Android NDK with C++ support". Nowadays CrystaX NDK differs very much from Google's one - mostly because Google isn't interested in evolving of native development for Android; but we're _very_ interested. Our main goal is to create powerful comprehensive toolkit for native development for Android, and in fact we're making it much better than Google do. We're strongly aim to continue working on CrystaX NDK and support Boost on Android - just because it's helpful to our NDK too, not only to the Boost community. However, since CrystaX NDK is fully open sourced and we're working on it without being paid by any organization, we need help from peoples interested in evolving of native development for Android. Since 2009 I was working on the project in partial time fashion, making money other way (being paid contractor and working on many commercial projects); but last eight months we have switched to the full time scheme, and have achieved significant results in last release. Now we want to continue working on it full time, improving it more and more, and making native development for Android easier. We've started fundraiser on https://www.bountysource.com/teams/crystaxndk/fundraiser to collect funds needed for us to continue working on CrystaX NDK full time. We're calling everyone interested in Boost-on-Android to help us - either by sponsoring us or providing contributions to our project. 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. Some links: https://www.crystax.net/android/ndk - CrystaX NDK project page https://tracker.crystax.net/projects/ndk - our bug tracker https://www.crystax.net/contact - here you could contact us directly -- Dmitry Moskalchuk
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/
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.
Yes, building Boost libraries with Google's Android NDK is straightforward, but just build libraries is not enough; it's good to have them _work_, not just _build_. Some Boost libraries are working good being built with Google's NDK, some not. And this is main difference between CrystaX NDK and Google's Android NDK - we're going to make _all_ Boost libraries work on Android, and the only way to do that is to use own NDK, because it impossible to do with Google's one. I'll describe it more detailed below.
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.
To be more specific: Google's Android NDK offer several implementations of C++ Standard Library - system (default), stlport, gnustl, libc++ (I'm naming them here as they are named in Google's NDK). Default one (system) is not actually real implementation - it only contains implementation of operator new; nothing more. stlport - well known STL implementation working on multiple platforms. However, it's a) not full C++ Standard Library implementation and b) it doesn't support C++11/C++14. gnustl - it's GNU libstdc++ from GCC upstream with Google's modifications. Even though it is GCC's implementation of C++ Standard Library, don't expect good C++ support from it - mainly because of defective Android libc implementation. On build stage, GNU libstdc++ configure scripts detect many things supported on target platform and, since many of them are not supported on Android, many C++ Standard Library features are become disabled. For example, you will not get std::stol, std::stoul etc - they are just not available in Google's gnustl. So it's not full implementation too. Another problem is std::chrono::monotonic_clock - do you know it's actually std::chrono::system_clock? I.e. you will not get any compiler/linker error - it just will not work properly. There are huge number of such problems, and all of them caused by defective Android libc implementation. 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. Now, what we did in CrystaX NDK to solve those problems. We have implemented big part of libc required by C standard in additional library libcrystax.so, which is added transparently to the link process _before_ Android libc, thus getting overridden buggy and non-implemented functions from Android libc. We've also significantly modified sysroot headers, making them much more POSIX-conforming than original. That allowed us to make GNU libstdc++ implementation _full_. We've paid special attention to that, fixing all things it expected from libc but not detecting on target platform. So using CrystaX NDK you'll get _actually_ full C++ Standard Library implementation, not _nominally_, as it is in Google's NDK. BTW, we've made this library 'default' in CrystaX NDK instead of defective 'system'. Second, we throw away Google's modifications of LLVM libc++ and using upstream LLVM libc++ with slight modifications, allowing use it with gcc, not only with clang. Again, this made it _much_ more stable, since we touched it minimally, preferring to fix underlying layer to fulfill standards rather than fixing LLVM libc++ itself. So developers have choice which C++ Standard Library implementation to use in CrystaX NDK - GNU libstdc++ or LLVM libc++. We offer both, and both working better than in Google's NDK.
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. Mainly because it will become nightmare to support all Android versions and take into account all peculiarities and bugs on Android libc (and remember, you'll need to add run-time checks to detect real Android version on device and apply different workarounds for different Android versions). This looks really wrong for me as for developer, so we offer another way - just use CrystaX NDK (which provide standard behaviour of underlying layer) and forget about Android libc bugs/incompatibilities/etc. CrystaX NDK is open source project, we offer it for free and we strongly aim to continue its development and support, so practically it's better choice than fighting with Google's NDK and fixing on your own all things we already fixed in CrystaX NDK. -- Dmitry Moskalchuk
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.
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
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. 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/
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.
Well, in ideal world - yes.
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.
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. 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; 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__).
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. -- Dmitry Moskalchuk
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/
Your NDK preceded Google's C++ support?
Yes. Google released NDK in 2009, and there was no support for C++ at all. There was tons of requests to add C++ support from developers in android-ndk group for a months, without any reaction from Google. Then I've started working on adding C++ support into NDK and to the end of 2009 I've published first version of CrystaX NDK. Anyway, even after that, being constantly pressured by developers community, Google have added C++ support only to NDK r5 (December 2010), and it was exactly my patches applied to the upstream (with minimal non-significant changes). Counting from beginning, it took almost two years before Google did that; and even when it was done, it was far from being _really_ _full_ C++ support. This is still true - Google's NDK still don't support C++ fully; in contrast with Google, we're paying special attention to do it as good as we can.
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 :)
Agreed. Me too :)
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.
We already test both "develop" and "master". You can see "master" results here: https://boost.crystax.net/master/developer/summary.html. But our results are not shown yet on http://www.boost.org/development/tests/master/developer/summary.html because we're not yet "approved" testers (as Rene Rivera said). However, test results are uploaded to Boost FTP so you can include our 'master' test results at any moment by making us 'approved' here: https://github.com/boostorg/regression/blob/develop/reports/src/boost_wide_r....
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.
No objections on that; I just wondering how to do that technically? Do you mean some existing web page? Or should we create new one? Or it should be just once-per-month e-mail to this list? -- Dmitry Moskalchuk
On Thu, Mar 19, 2015 at 7:48 AM, Dmitry Moskalchuk
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.
We already test both "develop" and "master". You can see "master" results here: https://boost.crystax.net/master/developer/summary.html. But our results are not shown yet on http://www.boost.org/development/tests/master/developer/summary.html because we're not yet "approved" testers (as Rene Rivera said). However, test results are uploaded to Boost FTP so you can include our 'master' test results at any moment by making us 'approved' here:
https://github.com/boostorg/regression/blob/develop/reports/src/boost_wide_r... .
That's correct :-) Actually I was only waiting for Dmitry to get complete coverage for the master tests to make them visible. So.. Are the master tests now all running? If yes.. Can you tell me the names of the testers I should open? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
That's correct :-) Actually I was only waiting for Dmitry to get complete coverage for the master tests to make them visible. So.. Are the master tests now all running?
We have nine configurations (ABI + API level) now, and all of them are running automatically for all Boost libraries. However, we'll add more configurations in the future - we'll add MIPS ABI, we're going to enable testing with -std=c++11, add separate testing with GNU libstdc++ and with LLVM libc++, etc. Anyway, what we have now looks good for start. You can assess it on your own: https://boost.crystax.net/master/developer/summary.html. The only thing I'm not sure in is frequency of updates - full test of all nine configurations took about 7 days now, utilizing 100% of CPU and memory of our servers. We've parallelized it as much as possible, but we just have no more free servers to run. Potentially we could decrease time of full tests run iteration to 1-2 days, running every configuration on separate server. So we're asking community to support us at https://www.bountysource.com/teams/crystaxndk/fundraiser, helping us to buy more servers and run tests quicker. Otherwise, tests results would be updated once every 7 days, until we'll have more resources.
If yes.. Can you tell me the names of the testers I should open?
All our runners names are beginning from "CrystaX.NET-", so adding 'CrystaX\.NET-.*' (or even 'CrystaX.*') should be enough. -- Dmitry Moskalchuk
On Thu, Mar 19, 2015 at 9:40 AM, Dmitry Moskalchuk
All our runners names are beginning from "CrystaX.NET-", so adding 'CrystaX\.NET-.*' (or even 'CrystaX.*') should be enough.
OK. I added it in. They will start showing up within an hour (IIRC the scheduled reports run correctly). -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On 19 Mar 2015 at 15:48, Dmitry Moskalchuk wrote:
Your NDK preceded Google's C++ support?
Yes. Google released NDK in 2009, and there was no support for C++ at all. There was tons of requests to add C++ support from developers in android-ndk group for a months, without any reaction from Google. Then I've started working on adding C++ support into NDK and to the end of 2009 I've published first version of CrystaX NDK. Anyway, even after that, being constantly pressured by developers community, Google have added C++ support only to NDK r5 (December 2010), and it was exactly my patches applied to the upstream (with minimal non-significant changes). Counting from beginning, it took almost two years before Google did that; and even when it was done, it was far from being _really_ _full_ C++ support. This is still true - Google's NDK still don't support C++ fully; in contrast with Google, we're paying special attention to do it as good as we can.
I take my hat off to you sir. Thank you for such a huge contribution to C++. And shame on Google for that matter. They should just cut you an annual cheque instead of poorly cloning your work.
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.
No objections on that; I just wondering how to do that technically? Do you mean some existing web page? Or should we create new one? Or it should be just once-per-month e-mail to this list?
I think the technical difficulty of an email once per month is nothing like the cultural difficulty here. We don't name and shame at Boost historically. I personally think we should, but it isn't my call to make. The general process of getting a decision is to generate consensus here on boost-dev somehow, and perhaps institute a voluntary opt in prototype with a few volunteer maintainers (I'll volunteer AFIO right now, and I can't see Vicente having a problem with Thread. Chris just patched ASIO to fix your test failures after I asked him, so I'd assume he'd be in too). After it's proven to work for some months and the community feels comfortable (or not) with it, you then formally ask the Boost Steering Committee for a resolution in favour of instituting it across the board. That's my best suggestion anyway. Obviously these are matters far wider than Android support, so it's a lot more thorny. For example, if a library repeatedly gets stuck at the top of that name and shame leaderboard, it could generate negative vibes around the library or its maintainers which has unhelpful effects on the community. We already have enough of that with Test. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
I think the technical difficulty of an email once per month is nothing like the cultural difficulty here. We don't name and shame at Boost historically. I personally think we should, but it isn't my call to make.
The general process of getting a decision is to generate consensus here on boost-dev somehow, and perhaps institute a voluntary opt in prototype with a few volunteer maintainers (I'll volunteer AFIO right now, and I can't see Vicente having a problem with Thread. Chris just patched ASIO to fix your test failures after I asked him, so I'd assume he'd be in too). After it's proven to work for some months and the community feels comfortable (or not) with it, you then formally ask the Boost Steering Committee for a resolution in favour of instituting it across the board.
That's my best suggestion anyway. Obviously these are matters far wider than Android support, so it's a lot more thorny. For example, if a library repeatedly gets stuck at the top of that name and shame leaderboard, it could generate negative vibes around the library or its maintainers which has unhelpful effects on the community. We already have enough of that with Test.
Yes, it's clearly understandable. I just thought such mechanism was already discussed and community already have kind of consensus on this. If not - well, let's wait for others, what they will say. -- Dmitry Moskalchuk
Forget to add something. See my comments below.
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. See current percentage of Android versions on the market: https://developer.android.com/about/dashboards/index.html. Android 5.0 is just 3% of current Android devices and I don't think this situation will be changed soon - just because Google don't control Android versions of market devices as Apple do for iOS. From practical point of view, it's absolutely needed to support at least Android 2.3, all 4.x and 5.x (several days ago Google released 5.1). We support all these versions in CrystaX NDK and provide backports of all fixes and features we implement in libcrystax, so think twice what would be better - use CrystaX NDK or dive into Google's NDK debugging worlds and spend weeks and months debugging and trying to workaround all bugs of that Android versions. 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. -- Dmitry Moskalchuk
participants (3)
-
Dmitry Moskalchuk -
Niall Douglas -
Rene Rivera