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 ?
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
> firstname.lastname@example.org mailing list
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"