search

dart-lang / build

A build system for Dart written in Dart
https://pub.dev/packages/build
BSD 3-Clause "New" or "Revised" License
792 stars 208 forks source link

in webdev, add logging for dartdevc with --verbose #1988

Closed jcollins-g closed 1 year ago

jcollins-g commented 5 years ago

Currently (build_web_compilers 1.0.0, Dart SDK 2.1.1-dev.2.0 on Linux), webdev build --no-release --verbose does not display information on what modules are built and where by dartdevc. This would be useful in understanding what the build system is doing under the hood and debugging problems.

jakemac53 commented 5 years ago

The easiest way to see what happened right now is to use the --track-performance argument and then load up the localhost:8080/$perf page (or whatever host/port you are serving your app on).

You will want to select the "hide skipped actions" option at the top.

jakemac53 commented 5 years ago

What specific information would you like the ddc builder to output here?

We could for instance output all the sources in each module that is compiled, or maybe just the first X of them (some might be large).

We also know the modules dependencies, but that would probably be very noisy. We could output the number of dependencies or something like that though.

jcollins-g commented 5 years ago

Probably listing all source files would be too much. I think what would be nice for my particular case is knowing what modules get built (even if there are many of them), and the top level source file for each one (omitting all other source files that aren't themselves independent modules).

jcollins-g commented 5 years ago

I don't actually know much about how ddc works with the build system, which is why this information would be helpful -- let me know if my terminology is incorrect or if I'm asking for something nonsensical.

jakemac53 commented 5 years ago

Don't worry what you are saying makes sense :).

Just for reference, there isn't really a way for a builder to collect a bunch of information about a build and then report that on the command line back to the user at the end of the build. All they can really do is log during an individual build step (compiling an individual module). This means the logs are interleaved with a bunch of other logs.

The verbose logging is already really noisy, so I am a bit skeptical if you would be able to make much sense of these logs because of that - they would get buried in a bunch of file events today. I think it is probably reasonable for us to remove those file event logs though, in which case you might be able to make sense of things, at least for smaller incremental builds with fewer actions.

In the meantime though, I do think it would be worth looking at the performance log page. It can be a bit daunting at first, but if you select "hide skipped actions" that trims down incremental builds a lot to something sensible. Then if you hover over an individual row you can see the primary input for that action. These will be *.ddc.module files, which correspond directly to a dart file which is the "primary" input for that module (being primary isn't really special though, its just a lexicographical ordering).