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
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
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to