Reland "Native assets support for Linux"

[dcharkes]

Reland of #134031. (Reverted in #135069.) Contains the fix for b/301051367 together with cl/567233346.

Support for FFI calls with @Native external functions through Native assets on Linux. This enables bundling native code without any build-system boilerplate code.

For more info see:

• ☂️ Native assets support #129757

Implementation details for Linux.

Mainly follows the design of #130494.

Some differences are:

• Linux does not support cross compiling or compiling for multiple architectures, so this has not been implemented.
• Linux has no add2app.

The assets copying is done in the install-phase of the CMake build of a flutter app.
CMake requires the native assets folder to exist, so we create it also when the feature is disabled or there are no assets.

Tests

This PR adds new tests to cover the various use cases.

• packages/flutter_tools/test/general.shard/linux/native_assets_test.dart
  • Unit tests the Linux-specific part of building native assets.

It also extends various existing tests:

• packages/flutter_tools/test/integration.shard/native_assets_test.dart
  • Runs (incl hot reload/hot restart), builds, builds frameworks for Linux and flutter-tester.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• All existing and new tests are passing.

[dcharkes]

The first commit is the revert of the revert.

The third commit reverts the second commit (which was a workaround), and contains the fix for b/301051367 together with cl/567233346.

[dcharkes]

Somehow, the 100something CI checks aren't triggering?

[drewroengoogle]

@dcharkes Is it intended to merge into main versus the current default master? Asking since the initial PR was being merged into master.

[dcharkes]

@dcharkes Is it intended to merge into main versus the current default master? Asking since the initial PR was being merged into master.

Aren't these aliases of each other?

[drewroengoogle]

@dcharkes Is it intended to merge into main versus the current default master? Asking since the initial PR was being merged into master.

Aren't these aliases of each other?

I don't fully understand the specifics on how the targets are generated yet, but it seems that the logic in our backend that determines which targets to run handles PRs merging to the "default" branch (master in this case) to PRs merging to other branches.

[dcharkes]

@dcharkes Is it intended to merge into main versus the current default master? Asking since the initial PR was being merged into master.

Aren't these aliases of each other?

I don't fully understand the specifics on how the targets are generated yet, but it seems that the logic in our backend that determines which targets to run handles PRs merging to the "default" branch (master in this case) to PRs merging to other branches.

Nice find, it looks like the CI is now running :)

Should I be using master instead of main in my local checkout? to branch out of?

[drewroengoogle]

@dcharkes Is it intended to merge into main versus the current default master? Asking since the initial PR was being merged into master.

Aren't these aliases of each other?

I don't fully understand the specifics on how the targets are generated yet, but it seems that the logic in our backend that determines which targets to run handles PRs merging to the "default" branch (master in this case) to PRs merging to other branches.

Nice find, it looks like the CI is now running :)

Should I be using master instead of main in my local checkout? to branch out of?

Yeah I think that would prevent this from occurring. I believe there are some github issues created to completely get rid of master that would make it even simpler in the future.

[stuartmorgan]

Should I be using master instead of main in my local checkout? to branch out of?

I exclusively branch from main locally; it shouldn't affect PR targets.

[dcharkes]

Friendly ping to review this PR @chingjun @stuartmorgan.

(Apparently, all my PRs end up having merge conflicts with g3, and get "deleted" roll CLs. I've verified the fix for this PR in g3 cl/566871401. So it should be safe to set g3 to green. Though, other stuff might have landed in the meantime, invalidating the old CL.)

[chingjun]

LGTM! The approach is a lot cleaner than I originally imagined :)

And for the g3fix, I think you only need to keep the first file in your g3fix CL, maybe that was the issue you're facing?