Link ICU data into the Cobalt binary

[hlwarriner]

With this change, Cobalt will no longer be deployed with an external ICU data file that must be loaded at runtime.

b/209049814

Change-Id: I8f67b3176181fa314f3e011ce4cf07fd4a671436

Test-On-Device: true

[hlwarriner]

This is another attempt at #838 and attempts to make the change for all architectures and platforms.

I'll want to do some manual testing on devices before merging this but wanted to share it now to get feedback. There are a few platforms I haven't yet tried to build for with these changes (e.g., Windows platforms), and I expect more work may be needed.

[hlwarriner]

This is another attempt at #838 and attempts to make the change for all architectures and platforms.

I'll want to do some manual testing on devices before merging this but wanted to share it now to get feedback. There are a few platforms I haven't yet tried to build for with these changes (e.g., Windows platforms), and I expect more work may be needed.

Yeah, I already see a build failure related to the assembly file on xbox. I'll look into it.

[oxve]

Looks like this ran into a similar issue as b/213960038: "compiler is out of heap space"

I suspect that the inclusion of the dat file could run into some limit on win32 builds (only xb1 and win32 failed). Have you been able to build this locally on win32?

[hlwarriner]

Looks like this ran into a similar issue as b/213960038: "compiler is out of heap space"

I suspect that the inclusion of the dat file could run into some limit on win32 builds (only xb1 and win32 failed). Have you been able to build this locally on win32?

Looks like this ran into a similar issue as b/213960038: "compiler is out of heap space"

I suspect that the inclusion of the dat file could run into some limit on win32 builds (only xb1 and win32 failed). Have you been able to build this locally on win32?

Thanks, yeah, we did build locally (thanks @andrewsavage1) and ran into different issues because the generated inline assembly was incompatible with MSVC. I'm setting up a Windows machine now and will be focusing on this.

[y4vor]

LGTM on my side

[hlwarriner]

Looks like this ran into a similar issue as b/213960038: "compiler is out of heap space"
I suspect that the inclusion of the dat file could run into some limit on win32 builds (only xb1 and win32 failed). Have you been able to build this locally on win32?

Looks like this ran into a similar issue as b/213960038: "compiler is out of heap space"
I suspect that the inclusion of the dat file could run into some limit on win32 builds (only xb1 and win32 failed). Have you been able to build this locally on win32?

Thanks, yeah, we did build locally (thanks @andrewsavage1) and ran into different issues because the generated inline assembly was incompatible with MSVC. I'm setting up a Windows machine now and will be focusing on this.

It took a few days but my Windows machine is now set up to a point where I can start building Cobalt and working on a fix. If I don't make progress in the next couple days, though, I'll likely modify this PR to only make the ICU data change for Evergreen for now. The time pressure exists only for Evergreen, and it looks like it wouldn't be too bad to have the build code branch on Evergreen for this behavior.

@y4vor @kaidokert FYI.

[hlwarriner]

Looks like this ran into a similar issue as b/213960038: "compiler is out of heap space"
I suspect that the inclusion of the dat file could run into some limit on win32 builds (only xb1 and win32 failed). Have you been able to build this locally on win32?

Looks like this ran into a similar issue as b/213960038: "compiler is out of heap space"
I suspect that the inclusion of the dat file could run into some limit on win32 builds (only xb1 and win32 failed). Have you been able to build this locally on win32?

Thanks, yeah, we did build locally (thanks @andrewsavage1) and ran into different issues because the generated inline assembly was incompatible with MSVC. I'm setting up a Windows machine now and will be focusing on this.

It took a few days but my Windows machine is now set up to a point where I can start building Cobalt and working on a fix. If I don't make progress in the next couple days, though, I'll likely modify this PR to only make the ICU data change for Evergreen for now. The time pressure exists only for Evergreen, and it looks like it wouldn't be too bad to have the build code branch on Evergreen for this behavior.

@y4vor @kaidokert FYI.

We discussed offline and do have a plan for win32: we'll skip the inline assembly and use NASM to assemble the generated data assembly. I converted this to a draft for now but should have a chance to upload a new commit early next week.

[hlwarriner]

Looks like this ran into a similar issue as b/213960038: "compiler is out of heap space"

I suspect that the inclusion of the dat file could run into some limit on win32 builds (only xb1 and win32 failed). Have you been able to build this locally on win32?

This seems to be resolved now; I'm guessing it was related to the inline data assembly file, which we're no longer generating.

[hlwarriner]

Looks like this ran into a similar issue as b/213960038: "compiler is out of heap space"
I suspect that the inclusion of the dat file could run into some limit on win32 builds (only xb1 and win32 failed). Have you been able to build this locally on win32?

Looks like this ran into a similar issue as b/213960038: "compiler is out of heap space"
I suspect that the inclusion of the dat file could run into some limit on win32 builds (only xb1 and win32 failed). Have you been able to build this locally on win32?

Thanks, yeah, we did build locally (thanks @andrewsavage1) and ran into different issues because the generated inline assembly was incompatible with MSVC. I'm setting up a Windows machine now and will be focusing on this.

It took a few days but my Windows machine is now set up to a point where I can start building Cobalt and working on a fix. If I don't make progress in the next couple days, though, I'll likely modify this PR to only make the ICU data change for Evergreen for now. The time pressure exists only for Evergreen, and it looks like it wouldn't be too bad to have the build code branch on Evergreen for this behavior.
@y4vor @kaidokert FYI.

We discussed offline and do have a plan for win32: we'll skip the inline assembly and use NASM to assemble the generated data assembly. I converted this to a draft for now but should have a chance to upload a new commit early next week.

Ok, this is ready for review again. Thanks for the discussion and ideas around this, @andrewsavage1 @kaidokert @osagie98.

[andrewsavage1]

As long as this is working on all platforms now it lgtm!

[kaidokert]

LGTM - it's great that a lot of GN deps get removed.

Please make sure that internal builds also run

[hlwarriner]

LGTM - it's great that a lot of GN deps get removed.

Please make sure that internal builds also run

The internal builds are now all succeeding. There are unrelated issues with the internal tests, so I'm planning to just go ahead and merge this today.