[native_assets_cli] `DynamicLoadingBundled` and `dryRun` in Flutter

[dcharkes]

Currently, in dryRun, Assets do not have to provide a file path.

However, in Flutter, the mapping from asset-id to file-name is used during dry-run to embed it in the kernel compilation.

So, for NativeCodeAssets with a linkMode DynamicLoadingBundled the file field should not be optional during dry run.

This currently blocks rolling the packages into flutter_tools.

(Maybe we can consider doing kernel concatenation to remove this requirement in the flutter implementation, maybe not. But that would be a separate larger refactoring.)

TODOs:

• Make native_toolchain_c output a file in dry run
• Make native_asset_cli check the field
• Roll packages and roll

[knopp]

With rust/cargo the asset path depends on target architecture. But with dryRun the target architecture is not provided.

[dcharkes]

Is it possible to come up with a file name? (E.g. not the full path.)

[knopp]

Sure, the file name itself is not architecute dependend, just the target directory. As long as the directory doesn't matter, and this is documented anywhere and the asset can't be constructed with null path this should be fine.

[dcharkes]

👍 Let's update the documentation to say that just Uri.file('filename.so/dylib/dll') is fine in dry runs.

In Flutter we only use the file name when bundling, not the absolute path.

Alternatively, we could make DynamicLoadingBundled take a file name. That would allow us to omit the file. Maybe that is cleaner. (Note that it would be a breaking change to the API once again, but we're doing that anyway atm.)

Any preference for either of the two solutions @knopp @mosuem ?

[knopp]

But at some point you need to know the full path so that you know which assets to lipo, right? Where would that go?

[dcharkes]

But at some point you need to know the full path so that you know which assets to lipo, right? Where would that go?

The dryRun is followed later by a "wet run" for all architectures for that OS later in the Flutter build.

[knopp]

Maybe I misunderstood. So you suggestion is DynamicLoadingBundled would have library name, always not null, while NativeCodeAsset would have nullable file (which is actually path)?

It seems to be bit weird to duplicate the file name in both cases. Also DynamicLoadingBundled is passed as link mode, it seems strange to have file name passed in link mode.

Maybe worth considering NativeCodeAsset having both directory (nullable) and fileName not nullable.