[native assets] Should surface stdout/stderr from build.dart

[craiglabenz]

When using the new native assets feature (#50565 and flutter/flutter#129757), the code that invokes build.dart seems to be burying its stdout and stderr.

I think it makes sense that end developers will not want to be bothered by log statements from these build steps, but seeing output / logging statements is important when writing or debugging build.dart.

I'm not sure how to differentiate between these two scenarios, but an escape hatch for build.dart authors would be a significant DX improvement.

cc @dcharkes @mit-mit

[dcharkes]

@mit-mit I believe I hid the logs on your request in the Dart SDK. 😄

[mit-mit]

My feedback was focused on the consumption use-case where it sounds like @craiglabenz agrees we should not show it.

Could we support seeing the output during development with a CLI flag or something like that?

[mosuem]

Even for end users who are not debugging their own build hooks, we should definitely show some kind of progress update IMO. If a user imports a package with a build or link hook invoking expensive operations, such as compiling a large native library from scratch, running dart run may take several minutes. For the user, it is invisible what is causing this.

Some possible options off the top of my head:

1: Show no progress (current situation)

• Pros: Clean empty output for dart run.
• Cons: Builds may take long time, involving multiple steps, the user is left in the dark about this. I personally always wonder if something crashed in my hook.

2: Show Running build hooks...

• Pros: Minimal impact on output.
• Cons: It's not clear which package is causing the delay, or how long it will take.

3: Show Running build hook for ${package.name}...

• Pros: User knows exactly who is causing the delay.
• Cons: Might be quite a lot of lines, if many packages have build hooks.

4: Let the package show it's own message

• Pros: Packages which have fast-running build hooks could opt to not show a message, while longer-running ones can give detailed updates, up to progress bars for downloads etc.
• Cons: Uncontrollable amount of output in the console for the end user. Worst case: package:ads_for_company pays package authors to include it's build.dart in packages, which is just a delay and some advertising text 🙃 (I hope this is against some policy of ours).

Opinions? @dcharkes @mit-mit @mariamhas @craiglabenz

[dcharkes]

I fear 3 and 4 might be too spammy.

Maybe we can do 2 in a similar style to Building package executable... (2.1s). E.g. we keep updating the seconds so that it shows the process isn't hanging.

If we want to make it less spammy we can show it only after 5 seconds.

And I believe we should do it in conjunction with dart-lang/native#97:

Running build hooks. For logs see .dart_tool/native_assets_builder/logs/20240730164559.txt. (10.1s)

[mit-mit]

I suggest 2) in the standard mode, and 3) when dart has been passed --verbose

[dcharkes]

I suggest 2) in the standard mode, and 3) when dart has been passed --verbose

If we want to align with Flutter -v, then --verbose should stream all stdout and stderr from all hooks. So that would be option 4.
(But flutter -v is so extremely verbose that it feels useless. So maybe we shouldn't be aiming to that.)