Based on feedback from the Dart team, we've shifted dart:gpu from a dart: library into a regular source package that interacts with the engine via dart:ffi. While this seems to work great locally, it does leave an open question as to how we would distribute this package to developers.

We'd like to avoid developing this package in flutter/flutter and instead develop it in flutter/engine so that the Dart code is co-located with the native APIs it is binding to. However, we don't currently have a standard means of doing so. Some options we potentially have:

• The engine -> framework autoroller could be configured to copy the source code of flutter_gpu from a particular engine directory to a particular framework directory. This would ensure that the engine binary is always used with the correct flutter_gpu version. This would also make sure that the framework git repo wasn't left dirty. Unfortunately, this would make the local engine development workflow harder, as we'd need to use dependency_overrides.

• The flutter tool could copy the flutter_gpu sources from some engine binary directory into an accessible source directory. This would require us to gitignore some folder in flutter/flutter or else we'd leave the git repo dirty. This may or may not work well with analysis, and may have implications for what source code is considered the source of truth. Similar issue as 1.

• The flutter SDK could include a package which essentially re-exports source code from a specified engine artifact directory using relative paths. This may only work with certain configurations of the SDK.

• The pub cmdline tool could be configured to look in a particular engine artifact directory, based on either heuristics or based on some configuration in the flutter/flutter repo. This would work similar to the sdk: flutter magic, which appends /packages/<package-name> to the flutter root known by pub.

FYI @Hixie @bdero @jonasfj