I didn't look at it in April, and I'm going to be messing with how we have the NDK repository set up for PDFium. I'll revisit this after that repository work is finished.
Note that with https://codereview.chromium.org/2132143002 Skia should now be working around https://llvm.org/bugs/show_bug.cgi?id=25608 . The real fix for that issue is to stop using gcc with libc++ (which is just a bug to begin with, for example explicit operators in the stl are no longer explicit among other things). If we can move to clang I would be so happy.
comment 22: there's a bug for switching to clang on android (blocked on arm code size mostly) somewhere, but i disagree that using libc++ + gcc is a bug. libc++ tries to support that config.
Hey, the "extract to own repo" bit sounds cool! Does this make it easier to deps in an ndk with mac binaries on mac? (I'm not asking for official support for using macOS as host for android builds, but that was one of the slightly more annoying things to hack up when I used that build config locally in the past)
I think it should be easier to do so by changing https://chromium.googlesource.com/android_tools/+/master/DEPS. (We don't have a mac version of the NDK checked in to https://chromium.googlesource.com/android_ndk/, though.)
caveats:
- I've never tried building using a mac as a host for an android build
- We use a lot of paths relative to the NDK in //build/config/android, though, and I haven't looked into whether those would work with a mac version of the NDK.
- This also obviously doesn't deal with the SDK, which also has a mac version and may present another obstacle to a mac host build.
I had it kind-of working a while ago at https://bugs.chromium.org/p/chromium/issues/detail?id=277641#c11 . I don't think there's enough demand to officially support that setup, but many of the changes needed for it seem like good hygiene anyhow (eg not checking in linux binaries as The NDK :-) ).
Sorry for the bug hijack though.
The roll has landed and stuck, so I suppose. I had planned to look into the arm64 size regression on cronet a bit more before marking it as such, but I'm not sure that I'm going to have much time to do so in the near future.
After this change, //third_party/android_tools/README.chromium contains obsolete NDK information still referring to r10e-rc4. I guess ndk info should be removed from there now that //third_party/android_tools/ndk/README.chromium exists.
I'd do it but I don't know the procedure for external contributions to android_tools, probably much easier for you to fix.
Comment 1 by thakis@chromium.org
, May 3 2016