On Thu, Dec 19, 2013 at 09:57:38AM +0000, David Chisnall wrote: > > On 19 Dec 2013, at 09:40, Luigi Rizzo <ri...@iet.unipi.it> wrote: ... > >> Oh, and when I do a build of LLVM/Clang on my laptop using Ninja, it takes > >> about 3-5 minutes, whereas when I do it with our build system it takes > >> about 15. When I do it on a 24-core server, it takes less than two > >> minutes with Ninja and with ours it takes about 15 (no speedup over my > >> laptop). I'd therefore suggest that there might be more pressing things > >> that need fixing with our antiquated build infrastructure than the > >> prettiness of the output... > >> > > these are orthogonal issues though, and so radically different in > > complexity that it does not seem a waste of energy to apply > > the patch i suggested while someone comes up with an improved build > > system. > > I disagree. These are the core issues. When the build works, everyone is > happy with the less-verbose output. When it fails, you want the most verbose > output. If a change is reducing the verbosity in the normal case, then > that's fine, but it should not reduce the verbosity in the case of error. > Ninja does this right. > > This is especially important with our build system, which can take several > minutes of doing nothing to get to the point where a build fails. It is a > serious productivity hit to have to wait that long to recompile a single file > and see whether it's fixed. By ensuring that, in the case of failure, we > have enough information in the terminal to reproduce the failing build step, > we can improve this a lot.
Respecfully, i think this is a non constructive digression. I never suggested to change the default verbosity, or remove the option to use -s or -v. Surely what you suggest is closer to ideal output, but i am proposing to apply the minuscule patch that I have submitted, whereas your proposal probably requires some massive effort for which nobody seems to have volunteered. So by all means speak up if i am proposing something incorrect or that induces regressions or harms maintainability, but "we could change the entire build system" is not a relevant argument. Regarding Ninja and ways to improve the build system, you make an interesting comment: > If a command exits with a failure condition, then Ninja dumps the exact > command line that was used, along with all of the output, and then stops. > Another side benefit is that Ninja always uses absolute paths for invoking > the commands and for arguments, and so you can always just re-run that single > failing command. our build system currently relies on a ton of environment variables that modify the behaviour of the compiler/command. Putting all the relevant context in a one-liner might be challenging. Maybe we could instead write the environment and command to a temp file whose name is listed in the quiet output, and then run the file itself as the body of the rule ? cheers luigi anyone) a lot of effort compared to the minuscule patch i have posted, and there dp the question is that you (not that you can really re-run the command from the log, because there might be a ton of environment variables that modify > David > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
