[native_assets_cli] Move BuildMode to [native_toolchain_c]
#1800
Conversation
| @@ -118,16 +99,13 @@ sealed class HookConfigBuilder { | |||
| required String packageName, | |||
| required OS targetOS, | |||
| required List<String> buildAssetTypes, | |||
| required BuildMode? buildMode, | |||
| // required BuildMode? buildMode, | |||
| @@ -207,6 +186,10 @@ final class BuildConfigBuilder extends HookConfigBuilder { | |||
| json[_dependencyMetadataKey] = { | |||
| for (final key in metadata.keys) key: metadata[key]!.toJson(), | |||
| }; | |||
| // TODO: Bump min-SDK constraint to 3.7 and remove once stable. | |||
There was a problem hiding this comment.
This function should no longer take dryRun instead it should hardcode it to false in the json.
There was a problem hiding this comment.
That would break the tests in native_toolchain_c that check that no assets are built if dryRun is true. We can only remove such functionality once we can bump the Dart SDK constraint to 3.7 stable (assuming we get all the refactorings landed in both Dart and Flutter before the branchcut for 3.7).
There was a problem hiding this comment.
This code here is the builder code (i.e. code for Dart SDK & Flutter SDK - which no longer set this to true), no?
The package:native_toolchain_c is for hook writers, it can still read the dry run (possibly produced by older versions of Dart SDK & older versions of Flutter SDK).
There was a problem hiding this comment.
The builder code is used to produce a config in the unit tests of native_toolchain_c (pkgs/native_toolchain_c/test/cbuilder/cbuilder_test.dart). Edit: It seems we don't have any expect that no asset is produced no dry run though, we should have had that. 🤓
|
@dcharkes when building a Flutter plugin on Windows, we need to select the precompiled library that was built with a runtime library matching the Flutter application (i.e. we can't mix debug ( Previously |
Oh that's very interesting! Could you elaborate on why your dylib has to match the build mode of Flutter? |
Setting aside Windows runtime variants, the simplest example would be a Flutter application that:
|
This behavior makes sense for the root package (and path dependencies and packages in your pub workspace), the ones that you are developing yourself. However, for arbitrary packages in your dependencies you'd want the dylibs to be compiled in release mode. For example if you have sqlite3 or cronet dylibs somewhere in your dependencies. If those packages are stable, you don't want the asserts to be run. Those packages depending on a build-mode from Flutter would mean those would also be in debug mode in Because we only want to change the behavior of the root package, I believe a better approach would be to flip the Most likely if you're developing the Dart code of your app and not touching the native code you might want to also run your native code in release mode while developing with hot reload with A second approach would be to use the user-defines in the workspace
I don't think I have enough background information here. Why would you need the compile mode to be identical with Flutter here? Isn't it the same as for other native dependencies, you only want it in debug mode if you suspect you have an error with it. Does this make sense? Maybe I don't fully understand your use-case or development workflow. Please elaborate if the above suggestions won't work. edit:
You mean you can't mix Flutter being in one mode and your dylib in the other mode? Or two of your own dylibs being in different modes? |
But what if I do want them to be run? :) I was hoping this could be a package-level choice. Not all compile options need to affect speed, e.g. maybe we want to use exactly the same optimizations but strip symbols for
Yes, that's a viable alternative. Is this available yet? I think I may have asked about this recently.
On Windows, a Flutter plugin is built as a DLL and can be linked against the debug ( |
Yes, in the very latest release on the master branch of flutter and the latest release of
So, this is not a need to have the same as the Flutter runtime, but the same between two native libraries linked together statically into a dylib. (This might be relevant at some point if we ever get to statically link the Flutter/Dart AOT runtime together with a Dart AOT snapshot together with static libraries from the build hooks. But we are rather far away from that.) Then that linking of multiple native libraries into a single dylib is happing in a single hook. So that hook should be able to make the choice correctly. Okay, if I understand correctly, user-defines should enable your workflow. (We don't have conditional user-defines though, so you'll have to toggle between debug/release manually. Maybe add a check on your CI which checks that the user-define equals release if the app version number is a non-prerelease.) |
Ah, great news.
Yes, I probably wasn't clear - this isn't about Flutter itself, it's about a Flutter plugin that builds/links some native library. I will investigate user-defines and see if that solves the issue. Thanks for taking the time to respond. |
The first in a series of refactorings to address:
BuildConfig.targetOStoBuildConfig.codeConfig.targetOS, remove it entirely or extend to cover web #1738We align
BuildModewithOptimizationLevel, it's configured by the hook author in the build hook. Likely, every package should ship with max optimization level and build mode set to release. Only while developing a package (when it is the root package or path-depsed in) would the build mode be set to debug.This will require a manual roll into dartdev and flutter tools due to the removal of
BuildModefrom thenative_assets_builderAPI.The native assets builder will still emit the field in the JSON, until we can bump the
native_assets_cliSDK constraint to 3.7 stable. Then only people with older versions of thenative_assets_clipackage but a newer SDK break.