Open dcharkes opened 1 month ago
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.
One slight issue is that the assetId
might not entirely be obvious when generating.
So maybe assetId
should be optional.
Something along the lines of:
# ffigen.yaml
native:
assetId: package:my_package/src/bindings_generated.dart
resource-identifers: true
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.htmlA 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?