Failure to identify a C compiler toolchain should not cause an error, only not set config.codeConfig.cCompiler

[mkustermann]

Currently the flutter build system checks if there's any packages with hooks and if so going to run the dart build. When it constructs a config it requires there to be a C compiler.

Though not all users may have a C compiler installed and the hooks may just provide pre-built binaries instead of building from source.

=> So we don't have to error if we can't find a C compiler, maybe the hooks that need to run don't actually need it.

This is related to making config.codeConfig.cCompiler nullable.

[dcharkes]

=> So we don't have to error if we can't find a C compiler, maybe the hooks that need to run don't actually need it.

I don't believe we do error. Dart standalone never provides the path to a CCompiler, so it should be already nullable?

[mkustermann]

We execute this whenever we invoke hooks and that calls down to e.g. cCompilerConfigAndroid which will throw if it can't find the NDK

There's even a test testing that an exception is thrown, see packages/flutter_tools/test/general.shard/isolated/android/native_assets_test.dart

[dcharkes]

Ah, you're filing an issue about flutter_tools in the dart-lang/native repo. It's better to file issues on the flutter/flutter for code in flutter/flutter, then there's more context.

(I can't transfer this issue, we can only transfer issues between repos in the dart-lang org.)

I believe we always need a C compiler for the target platform to do flutter run / flutter build, which can be validated by running flutter doctor. If flutter doctor does not mandate a native compiler, we must make it nullable indeed.

Of course for data assets, we start invoking it for non native targets, so this whole step should be skipped.

Changing the logic to make it nullable instead of erroring sgtm. As long as we have at least one test covering that we're not simply omitting it always because it just happens to be nullable.