The standalone NDK's problem is that we moved to use the same C++ standard library as Firefox in order to match SM when Gecko made the move. Unfortunately, the make-standalone-toolchain.sh script was broken for years for anything apart from the default C++ standard library (it would either just break using wrong directories or fail to pick up all the right headers, depending on the version). Therefore, I adopted the identical strategy for picking up headers and setting include paths that Firefox was using, again to make sure we picked up the same definitions since we were passing those flags down to SM.
If that has since been fixed, I'm not against returning to the standalone NDK, though tbh it was also a huge source of user confusion. We had versioned SDK and NDK directories but then an *unversioned* NDK toolchain directory that developers needed to know to blow away and update every time they picked up a new version. Certainly, could automate this away per your suggestion below! - Lars On Wed, Mar 7, 2018 at 8:48 AM, Josh Bowman-Matthews <j...@joshmatthews.net> wrote: > On 3/7/18 6:04 AM, Imanol Fernández wrote: > >> We talked a bit about standalone NDKs when we worked on adding support for >> new android CPU architectures here: >> https://github.com/servo/servo/issues/11921#issuecomment-299052122 >> >> The benefit of using a standalone NDK is that we have to configure less >> CXX >> flags in Servo. But the main concerns are that is another step and failure >> point for people building for Android. Also we have to create different >> standalone NDKs for each architecture: armv7, arm64, x86, etc which can >> increase build sizes and steps for the user. >> >> IMO is better that we assume the CXX flags set up complexity and only make >> the users to set up the PATH to the default android-ndk folder. At least >> that's the usual way to compile android libraries. In fact, I had never >> heard of standalone NDKs after a lot of time working & compiling libs for >> Android until I worked on that Servo integration. >> > > One way we could continue to assume the complexity is by creating the > standalone NDK as part of the regular build. If the build system checks for > a .android directory that contains an NDK for the desired target, it goes > ahead and builds with the right settings. Otherwise, it checks for the > presence of the ANDROID_NDK path and invokes the make_standalone_ndk.sh > with the right arguments to create one in .android. > > > Cheers, > Josh > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
