search

dart-lang / native

Dart packages related to FFI and native assets bundling.
BSD 3-Clause "New" or "Revised" License
153 stars 43 forks source link

[native_assets_cli] Access to dart_api.h and dart_api_dl.h + passing in the api version #839

Open dcharkes opened 10 months ago

dcharkes commented 10 months ago

When compiling native code from source, it would be nice if we'd compile against dart_api.h or dart_api_dl.h from the Dart/Flutter SDK that is invoking build.dart. This would prevent version skew between the native API and the Dart VM.

It would not prevent version skew with precompiled binaries, as they already have been compiled.

To prevent version skew with precompiled binaries we'd need to pass dart_api_version.h's version as an argument as well, so that the users can precompile a version per Dart API. This would be analogous to what python is doing. (@brianquinlan You pointed to examples of this earlier, but I can't seem to find where you did that.) Note that at this point you'd need an older Dart SDK to precompile a dylib to an older API version.

brianquinlan commented 10 months ago

To prevent version skew with precompiled binaries we'd need to pass dart_api_version.h's version as an argument as well, so that the users can precompile a version per Dart API. This would be analogous to what python is doing. (@brianquinlan You pointed to examples of this earlier, but I can't seem to find where you did that.) Note that at this point you'd need an older Dart SDK to precompile a dylib to an older API version.

I think that I showed you the downloadable files associated with a Python package, e.g. for tensorflow.

You can see that the names are like "tensorflow-2.15.0-cp311-cp311-macosx_12_0_arm64.whl"

So this is the file that will be downloaded if you install tensorflow 2.15 for Python 3.11.x on a ARM64 mac. 0.0.x version changes never break ABI compatibility but all other version changes are assumed to break ABI compatibility.

There is a limited API that is guaranteed to be ABI compatible for all of Python 3.x.x (3.0 was released 15 years ago and there are still no plans for a 4.0).

I'm not advocating for this, just explaining how it works ;-)

I would advocate for allowing some sort of binary packaging so that users don't need a compiler to use packages containing native code.

dcharkes commented 10 months ago

I would advocate for allowing some sort of binary packaging so that users don't need a compiler to use packages containing native code.

Yes, that is totally possible with the native assets feature. (And passing the dart_api_version would keep the precompiled capabilities on par with the on-demand-compiled capabilities when adding the path to dart_api_dl.h and friends.)