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