Re: [dev-servo] Standalone NDK concerns?
On 07.03.2018 17:15, Nathan Froyd wrote: 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 Actually, this should have been done aeons ago - and the whole idea of all these "sdk"'s is pretty ridiculous. Instead there should be an clean separation between individual packages (incl. kernel, bootloader, etc), toolchains (compiler, binutils, ...) and the distro buildsystem system (eg. debuild, buildd, ...) and target- as well as dist-specific confguration. That's pretty much what we're doing w/ debian world as well es embedded kits like ptxdist. For an android-alike system that primarily means: * different c-library (which nowadays wouldn't be necessary anymore, as non-ancient mobile handsets are strong enough for running plain glibc+friends) ... historically there had been a strong connection between libc and gcc (had to be compiled together, to fit each other), but that also had been lifted long ago (IIRC clang never had that problem) * customized kernel, bootloader, image layouts, etc (basically what ptxdist calls the platform configuration) * additional java->dalvik compiler All the rest is just usual sw packages ... pretty boring from build engineering pov. Unfortunately, Google doesn't wan't an simple and straightforward, easily understandable and customizable system. (it's really time for creating an own mobile/handheld distro) For servo, we'd have to add the rust toolchain (configured for the particular target - within an arch, it should be pretty generic). It's long ago since I touched android the last time, but IMHO, the first step should be integrating rust into several distros - up to the esoteric ones like android - then treat servo as just yet another library package. Actually, servo shouldn't be a library, but a dedicated (server) application, which the integrating application just talks to, but doesn't link against (the Plan9 / suckless approach). I did some experiments in that direction several months ago, but yet lacking time for deeper involvement. One thing's absolutely clear for me: give up the whole concept of SDKs as such. It never fits well and just horrible to maintain. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287 ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Standalone NDK concerns?
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?
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?
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
Re: [dev-servo] Standalone NDK concerns?
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
Re: [dev-servo] Standalone NDK concerns?
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 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