[native assets] Inconsistent logging on error.

[knopp]

When native assets build.dart fails during flutter build, its output should be printed. This doesn't currently happens consistently.

macOS (xcodebulld):

• stdout is printed
• stderr is printed twice

linux (CMake / Ninja):

• stdout is printed only with verbose flag (-v)
• stderr is printed as expected

windows (CMake / MSBuild):

• neither stdout or stderr is printed without verbose flag (-v)
• with verbose flag stderr is printed twice.

Out of these windows seems worst, as the error gets swallowed by default, and it needs to be looked up in the full log, with quite a bit of text printed after the main error.

[knopp]

cc @dcharkes

[dcharkes]

Thanks for reporting @knopp!

windows (CMake / MSBuild):

• neither stdout or stderr is printed without verbose flag (-v)

Yeah, this is a known issue. Even errors from flutter assemble directly are not visible without -v:

https://github.com/flutter/flutter/blob/456f0101fd26601ea3352c620ed1bac5ac122542/packages/flutter_tools/test/integration.shard/isolated/native_assets_test.dart#L253

Basically stdout/stderr need to bubble up through the following process call graph:

flutter run -> xcodebuild, cmake, ninja, msbuild -> flutter assemble -> dart path/to/build.dart

I believe the windows issue is due to msbuild swallowing all the output from flutter assemble. So that's not really a native-assets specific issue. I'm not entirely sure how to solve that one. E.g. maybe always run msbuild in verbose mode and filter the output? Any ideas @christopherfujino?

Should our goal be to do stderr always and stdout only in verbose mode? Or should we also print stdout in non-verbose if the exit code of dart path/to/build.dart is non-zero? @christopherfujino @knopp

stderr is printed twice

with verbose flag stderr is printed twice.

The stdout/stderr from dart path/to/build.dart is streamed into this logger:

https://github.com/flutter/flutter/blob/456f0101fd26601ea3352c620ed1bac5ac122542/packages/flutter_tools/lib/src/build_system/targets/native_assets.dart#L80

We're happy to receive contributions.

This should probably be covered by an integration test that runs xcodebuild, msbuild, ninja.

[knopp]

Yeah, this definitely seems like something I'm going to need to spend a weekend on. Especially on windows the situation is pretty bad because the error is either swallowed completely (without verbose logging), or you need to look through a wall of text because the error in verbose log is usually several pages in the middle.

It might also not always be possible to easily determine what was stdout and stderr, I'm wondering whether the build tool could insert some markers in the text that would survive msbuild and and flutter run could use to extract the relevant part.

[dcharkes]

I'm wondering whether the build tool could insert some markers in the text that would survive msbuild and and flutter run could use to extract the relevant part.

Yes, I had the same idea. Always run the msbuild in verbose mode and don't stream stdout if Flutter is not in verbose mode. We'd also need to check if there is anything else worth capturing besides the build.dart hook output.

I'm not sure I'm the best person to make a call here, since this issue is wider than only the build hook output. @christopherfujino What are your thoughts? And anyone who we should loop in here?

[andrewkolos]

I've been affected by this on Windows, so +1 from me.

I'm thinking stderr output from flutter assemble should always bubble up to flutter run, or at least when flutter assemble exits with non-zero. However, I don't have any novel ideas for how to make this happen. The idea of inserting markers and parsing on them could work (even if this isn't a perfectly-elegant solution).

Or should we also print stdout in non-verbose if the exit code of dart path/to/build.dart is non-zero?

This I'm less sure about. I'm keen to be conservative and not log all of stdout (maybe we can log a breadcrumb about rerunning with --verbose to see full output).