[native_assets][ffi] Make `build.dart` path configurable

[dcharkes]

@mit-mit proposed the idea of using build.dart for other things besides native assets.
Apparently, users are already doing this: flutter/flutter#138727 (comment)

This means the native assets feature needs to know whether to run not based on the existence of a top-level build.dart, but instead on a pubspec config.
Moreover, we might want to then also support running a script with a different name.

Possible pubspec config:

native_assets: #optional
  build: build.dart #optional
  link: link.dart #optional

[mraleph]

Instead of making it configurable I suggest we consider making a breaking change gated by SDK version constraint, e.g. starting from 3.3 top-level build.dart is reserved for native assets.

Another option is to require something specific in the build.dart, e.g. it should contain // @build line (or something similar).

[mit-mit]

If we're going to do that, I think we need to pick a more specific/detailed file name than build.dart

[mit-mit]

I suggest build_assets.dart and link_assets.dart

[dcharkes]

These names make sense to me, given what kind of assets we're considering adding:

• native code assets (native assets)
• data assets
• wasm code assets

I can easily make a change to do this. Do we then also want to cherry pick that change to Dart 3.2 and Flutter stable?
(The feature is not available on Flutter stable, but Flutter stable currently checks if build.dart exists to give an error message that the feature is not enabled. This might change though if flutter/flutter#138855 is landed.)

Instead of making it configurable I suggest we consider making a breaking change gated by SDK version constraint, e.g. starting from 3.3 top-level build.dart is reserved for native assets.

We can do this per dependency, relying on "languageVersion": "3.0" in the package_config.json.

The lower bound should be 3.2 if we cherry pick.
Otherwise the lower bound should probably be 3.3.0-whatever. Except for we don't have access to that information in the package_config.json. So we would need to parse the pubspec.yaml for every package.

Any ideas on how to enforce this for our users? Documentation and a breaking change announcement?

Or should we skip the SDK constraint, as (famous last words) no one uses build_assets.dart and link_assets.dart?

cc @mosuem @mkustermann for name change.

[mit-mit]

It's an experimental feature, so any reason why we can't simply make the naming change in main and let that be it?

[dcharkes]

It's an experimental feature, so any reason why we can't simply make the naming change in main and let that be it?

Because we added a check that if build.dart exists, but the experimental feature is not enabled, we issue an error. And users are hitting this on stable. flutter/flutter#138727 (comment)

[mit-mit]

Oh, yeah that part does sound cherry pick worthy

[dcharkes]

FYI, because the logic is inside package:native_assets_builder, the cherry pick in the Dart SDK is DEPS cherry pick.
Similarly, the cherry pick in Flutter is a flutter_tools pubspec.yaml cherry pick.

[mkustermann]

No particular opinion about the naming (though I prefer shorter over longer).

Regarding pubspec.yaml specifying the paths: It's backwards compatible to add feature to allow pubspec to set different name, but we're not required to do that right now. We probably want to reduce ceremony, so we may not want to require it.