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 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 <>

> 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:
>> 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
> with the right arguments to create one in .android.
> Cheers,
> Josh
> _______________________________________________
> dev-servo mailing list
dev-servo mailing list

Reply via email to