Closed Bug 1262569 Opened 4 years ago Closed 1 year ago
Turn off printing of the files that we're building as we build by default
58 bytes, text/x-review-board-request
58 bytes, text/x-review-board-request
This list of files doesn't really provide any value. Because we parallelize better, it's basically not possible to use the list of files as a proxy for progress.
If we do this, can we make it controllable by a setting in mozconfig? I definitely like seeing the output as a sign of progress. A percentage complete output would cover this, though.
I'll hack up a patch.
Assignee: nobody → gps
Status: NEW → ASSIGNED
Multiple people have complained that the build output of printing the source files being built adds little value. I agree. The extra output doesn't give really helpful progress info because sources can be built in non-deterministic order. Furthermore, the extra output hides useful output like compiler warnings. This patch makes the default build system output even less verbose. We no longer print the individual source targets when they are built. We do still print the targets for binaries, so some sense of progress can be inferred. If people like verbosity, they can export the undocumented BUILD_VERBOSE_LOG environment variable can be set to restore the old behavior. Review commit: https://reviewboard.mozilla.org/r/44687/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/44687/
Attachment #8738732 - Flags: review?(ted)
Comment on attachment 8738732 [details] MozReview Request: Bug 1262569 - Do not print individual source targets being built; r?ted https://reviewboard.mozilla.org/r/44687/#review41425
Attachment #8738732 - Flags: review?(ted) → review+
https://reviewboard.mozilla.org/r/44687/#review41431 ::: config/rules.mk:870 (Diff revision 1) > > $(OBJS) $(HOST_OBJS) $(PROGOBJS) $(HOST_PROGOBJS): $(GLOBAL_DEPS) > > # Rules for building native targets must come first because of the host_ prefix > $(HOST_COBJS): > - $(REPORT_BUILD) > + $(REPORT_BUILD_VERBOSE) REPORT_BUILD is also emitted by the backend and used in other Makefiles. You'd have better results changing the definition of REPORT_BUILD than by adding REPORT_BUILD_VERBOSE.
I tried something like this a couple of years ago and too many people complained so it got reverted. Worth trying again, though :)
Review commit: https://reviewboard.mozilla.org/r/45187/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/45187/
Comment on attachment 8739310 [details] MozReview Request: Bug 1262569 - Actually disable all REPORT_BUILDs. r?gps https://reviewboard.mozilla.org/r/45187/#review41765 In the original patch, I specifically limited the printing of source related targets and retaining printing of binaries. The reason was I wanted to retain some indication of progress during the build. With this patch, we have no progress indicators during compilation except for compiler warnings. With this patch, we can go multiple minutes without printing anything. This can lead to the impression the build has stalled. I favor eventually not printing anything except warnings and other important messages (basically what this patch does). However, I insist we have some kind of progress indicator before we do that. I was toying with the idea of restoring the X/Y progress indicator during the compile tier. I know you had good reasons to remove it. Perhaps we can come up with something better than directories for the thing being measured.
> I favor eventually not printing anything except warnings and other important > messages (basically what this patch does). However, I insist we have some > kind of progress indicator before we do that. Would the progress indicator work if you redirect the output of `mach build` to file or through a pipe? I ask because I pipe the output through my own script that pulls out error messages. (See https://lists.mozilla.org/pipermail/dev-platform/2015-January/008270.html and replies for old discussion on dev-platform about this.)
The leave-open keyword is there and there is no activity for 6 months. :gps, maybe it's time to close this bug?
Status: REOPENED → RESOLVED
Closed: 4 years ago → 1 year ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.