Re: [dev-servo] Standalone NDK concerns?

[Enrico Weigelt, metux IT consult via dev-servo]

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?

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

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

[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

Re: [dev-servo] Standalone NDK concerns?

[Matt Brubeck]

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

[dev-servo] Standalone NDK concerns?

[Josh Bowman-Matthews]

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