On Thu, Dec 19, 2013 at 09:57:38AM +0000, David Chisnall wrote: > > On 19 Dec 2013, at 09:40, Luigi Rizzo <rizzo_at_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_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"Received on Thu Dec 19 2013 - 16:44:15 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:45 UTC