Re: [dev-servo] Standalone NDK concerns?

2018-03-07 Thread Nathan Froyd
FWIW, the Android team is planning on making standalone toolchains
obsolete in the relatively near future (the roadmap says later this
year):

https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md#make-standalone-toolchains-obsolete

-Nathan

On Tue, Mar 6, 2018 at 7:46 PM, Josh Bowman-Matthews
 wrote:
> I'm trying to update our NDK from 12b to a more modern 16b. Since the
> default NDK installation is so convoluted in terms of include/lib/bin
> directories, I'm giving the standalone SDK a shot and it appears to be much
> more straightforward to integrate into the build. Is there any reason we
> haven't required the use of standalone SDKs before?
>
> 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


Re: [dev-servo] Standalone NDK concerns?

2018-03-07 Thread Lars Bergstrom
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 
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


Re: [dev-servo] Standalone NDK concerns?

2018-03-07 Thread Imanol Fernández
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.


On 7 March 2018 at 06:42, Matt Brubeck  wrote:

> We used to use a standalone toolchain:
> https://github.com/servo/servo/wiki/Building-for-Android/
> 16f371c68d7da393d178646dcb18dac2c2ea8826
>
> but this changed back in 2016; I'm not clear on the exact reasons:
> https://github.com/servo/servo/pull/13945
>
> On Tue, Mar 6, 2018 at 4:46 PM, Josh Bowman-Matthews <
> j...@joshmatthews.net>
> wrote:
>
> > I'm trying to update our NDK from 12b to a more modern 16b. Since the
> > default NDK installation is so convoluted in terms of include/lib/bin
> > directories, I'm giving the standalone SDK a shot and it appears to be
> much
> > more straightforward to integrate into the build. Is there any reason we
> > haven't required the use of standalone SDKs before?
> >
> > 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
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo