You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Alternatively, we can make FFIgen generate the resource identifier annotations. Are there any cases where we don't want the resource identifier information? Maybe if a package only supports dylibs, so tree shaking cannot be used anyways, then it should run FFIgen without adding the annotations.
(If we want to do the mapping automatically in the Dart SDK, we should move this issue there. If we want to generate the annotations in FFIgen, we should keep it here.)
SGTM - I think I prefer using the approach of adding ResourceIdentifier in ffigen, it makes the process a bit more visible for an otherwise already very opaque feature. Also, it pollutes the resources.json file less.
We should consider making
@Native
s automatically be mapped to@ResourceIdentifier
s.@Native
s have asymbol
andassetId
(both possibly inferred).https://api.dart.dev/stable/3.3.3/dart-ffi/Native-class.html
@ResourceIdentifier
s only have aObject? metadata
.https://pub.dev/documentation/meta/latest/meta/ResourceIdentifier/ResourceIdentifier.html
A possible mapping would be
->
Alternatively, we can make FFIgen generate the resource identifier annotations. Are there any cases where we don't want the resource identifier information? Maybe if a package only supports dylibs, so tree shaking cannot be used anyways, then it should run FFIgen without adding the annotations.
(If we want to do the mapping automatically in the Dart SDK, we should move this issue there. If we want to generate the annotations in FFIgen, we should keep it here.)
cc @mosuem thoughts?
The text was updated successfully, but these errors were encountered: