Cross-compiling artifacts for Android during Chrome OS builds

[Ken Rockot]

I would like to explore the possibility of generating native Android build artifacts during Chrome builds for Chrome OS. I know this is technically feasible as I have a local PoC using explicit GN toolchain references, with only minimal changes to some existing android GNI.

The main issue I can imagine is that this requires Chrome OS Chrome builders to pull in Android DEPS, a la .gclient target_os=["android"], in order to get at least NDK and relevant dependencies.

Would this be an unreasonable goal to pursue?

For full context, I'm looking to ship a shared library with Chrome in the Chrome OS system image. One copy of this library will exist for Chrome OS system services to consume, and another copy (actually two copies, 32- and 64-bit) will need to exist for native code in the ARC++ container to consume. All builds of the library must be built from the same Chrome revision, and the Android ones obviously need to build against Bionic etc.

The simplest thing to do from my naive perspective would be to require pulling Android DEPS for Chrome OS Chrome builds, and add a relatively small chunk (~50 lines) of GN to produce the cross-compiled libraries as needed.

[Stéphane Marchesin]

We have a setup like this for ARC++ graphics drivers, except that we
build everything as part of the Chrome OS build system, because this
needs a toolchain+headers etc. It provides packages for these
dependencies (toolchain+headers), just enough to build everything. I'm
ccing Nicolas who will know more.

Stéphand

> --
> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
> ---
> You received this message because you are subscribed to the Google Groups
> "Chromium-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to chromium-dev...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CA%2BapAgF_XEm5B7dsYW8w963P4%2BkK6JSC_SZMkbsutVfWegm9zA%40mail.gmail.com.

[Dirk Pranke]

On Mon, Apr 23, 2018 at 5:02 PM, Ken Rockot <roc...@chromium.org> wrote:

I would like to explore the possibility of generating native Android build artifacts during Chrome builds for Chrome OS. I know this is technically feasible as I have a local PoC using explicit GN toolchain references, with only minimal changes to some existing android GNI.

The main issue I can imagine is that this requires Chrome OS Chrome builders to pull in Android DEPS, a la .gclient target_os=["android"], in order to get at least NDK and relevant dependencies.

Would this be an unreasonable goal to pursue?

This isn't an unreasonable goal, but as you've seen in the other responses, doing this properly for a full (ebuild) CrOS build is a bit more complicated.

Apart from that, I'm also concerned about what the impact on the compile time might be. What will need to be built for Android?

-- Dirk

For full context, I'm looking to ship a shared library with Chrome in the Chrome OS system image. One copy of this library will exist for Chrome OS system services to consume, and another copy (actually two copies, 32- and 64-bit) will need to exist for native code in the ARC++ container to consume. All builds of the library must be built from the same Chrome revision, and the Android ones obviously need to build against Bionic etc.

The simplest thing to do from my naive perspective would be to require pulling Android DEPS for Chrome OS Chrome builds, and add a relatively small chunk (~50 lines) of GN to produce the cross-compiled libraries as needed.

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

[Ken Rockot]

On Tue, Apr 24, 2018 at 8:36 AM Dirk Pranke <dpr...@chromium.org> wrote:

On Mon, Apr 23, 2018 at 5:02 PM, Ken Rockot <roc...@chromium.org> wrote:

I would like to explore the possibility of generating native Android build artifacts during Chrome builds for Chrome OS. I know this is technically feasible as I have a local PoC using explicit GN toolchain references, with only minimal changes to some existing android GNI.

The main issue I can imagine is that this requires Chrome OS Chrome builders to pull in Android DEPS, a la .gclient target_os=["android"], in order to get at least NDK and relevant dependencies.

Would this be an unreasonable goal to pursue?

This isn't an unreasonable goal, but as you've seen in the other responses, doing this properly for a full (ebuild) CrOS build is a bit more complicated.

I'm not sure I see why we'd need to worry about ebuilds at all if this can be expressed entirely though GN within the existing Chrome build. The chromeos-chrome ebuild shouldn't need to change, and we shouldn't need to introduce any others.

Apart from that, I'm also concerned about what the impact on the compile time might be. What will need to be built for Android?

Basically just Mojo and its dependencies (//base, //ipc), against NDK toolchain. It is a relatively small addition to compile time. I was worried more about the additional cost of syncing extra deps, but maybe that's not so bad.

[Ken Rockot]

Here is the PoC Chromium CL which I believe accomplishes what I want: https://chromium-review.googlesource.com/c/chromium/src/+/1026203

 Of course this won't actually build on any builders that aren't syncing with a .gclient target_os=["android"]

[Don Garrett]

I'd like to hear which builds you expect to produce these artifacts, and how you will version and consume them. But it doesn't seem unreasonable.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CA%2BapAgEL7RqMmwvDd-hURkdgJRwV6ophbbev0S95WYpVe%3D5%2B-g%40mail.gmail.com.

[Ken Rockot]

On Tue, Apr 24, 2018 at 11:08 AM Don Garrett <dgar...@chromium.org> wrote:

I'd like to hear which builds you expect to produce these artifacts, and how you will version and consume them. But it doesn't seem unreasonable.

I expect all Chrome OS Chrome builds to produce these artifacts. There is no versioning as the library is designed to be ABI-stable (forward-compatible) indefinitely.

[Ken Rockot]

An updated CL to accomplish this is here: https://chromium-review.googlesource.com/c/chromium/src/+/1026203 -- of course it will be red on all Chrome OS builders because it now requires Android DEPS.

If I wanted to experiment with making Chrome OS builders pull in Android DEPS, how can I do that? i.e. where do changes need to be made and who needs to approve them?

[Dirk Pranke]

You might be able to test that by adding `'checkout_android': 'checkout_chromeos or checkout_android'` to the `vars = { ... }` block in DEPS. If that doesn't work, that might be something we can fix in gclient. Something like that is probably the right way to fix it (i.e., that sounds like it models the dependency correctly), and would only need to be approved like any other normal CL, though in this case it'd probably be best for jbudorick@ or I to review it.

Failing that, you can change the conditions in the DEPS file so that everywhere you have `checkout_android` you'd have `checkout_android or checkout_chromeos`. This might not work if there are dependencies in other DEPS files that are recursed into (like src-internal) and so you'd probably need the first fix for that.

 -- Dirk

[Ken Rockot]

On Wed, Apr 25, 2018, 9:12 AM Dirk Pranke <dpr...@chromium.org> wrote:

You might be able to test that by adding `'checkout_android': 'checkout_chromeos or checkout_android'` to the `vars = { ... }` block in DEPS. If that doesn't work, that might be something we can fix in gclient. Something like that is probably the right way to fix it (i.e., that sounds like it models the dependency correctly), and would only need to be approved like any other normal CL, though in this case it'd probably be best for jbudorick@ or I to review it.

Failing that, you can change the conditions in the DEPS file so that everywhere you have `checkout_android` you'd have `checkout_android or checkout_chromeos`. This might not work if there are dependencies in other DEPS files that are recursed into (like src-internal) and so you'd probably need the first fix for that.

I see, thanks! I was expecting to have to change some bot configurations or something, but if gclient target_os just translates to a checkout_android, this seems like a good plan.