Bazel: Don't hide compilation warnings

Created on 12 Apr 2019  路  8Comments  路  Source: bazelbuild/bazel

Description of the problem / feature request:

When I bazel build //some:target and it produces a compilation warning (I'm dealing with C++, but this is true with any language) bazel shows the warning. However if I bazel build //some:target a second time, the warning is cached and I don't see it at all. This is _very_ problematic in a certain workflow: When there are lots of warnings in lots of files, I build and see a long list of warnings which I start fixing. I fix a bunch of them, then bazel build again to see any remaining ones, however it hides warnings in files which haven't changed since the last bazel build! The only way to see them is to bazel clean and bazel build again, which can take a long time because I have to rebuild my whole project.

Feature requests: what underlying problem are you trying to solve with this feature?

Bazel's handling of compilation warnings is high unexpected to the user. We expect to see the same warnings from an untouched file _every_ time we build.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Make a cc_library target with a small C++ file with a compilation warning in it. bazel build //that:target twice in a row. Witness the warning displayed the first time, and hidden the second time. This is a major usability problem in a common workflow.

What operating system are you running Bazel on?

Ubuntu 14.04

What's the output of bazel info release?

release 0.24.1

P4 team-Local-Exec feature request

All 8 comments

This sounds more like it is Bazel simply not rebuilding files which have not changed. Like this

bazel build //some:target       # (containing 10 .cc files)
get warnings from all 10 files
fix 2
bazel build //some:target
see no more warnings

That is what I would expect, because the actions to recompile the untouched .cc files do not need to be re-executed. It sounds like you want a feature such that bazel would capture warning messages during the first build, and provide a way to force rebuild of those things that had warnings. Doing that feature in a generic way would be infeasible. As you said, it could be any language, so we can not reliably catch the warnings from all possible compilers.

You could do some scripting to capture warning messages & brew that down the list of files which you want to keep rebuilding each time. That will still have problems because there is no way to tell Bazel to force dropping analysis for particular files.

The other way around this is to build with -Werror. Then you have to fix the warnings as you go.

Did I understand your feature request the right way?

It sounds like you want a feature such that bazel would capture warning messages during the first build, and provide a way to force rebuild of those things that had warnings.

No, bazel doesn't know what a warning is, it only knows "did the action return 0 and did it print anything to stdout/stderr". The new feature would be to re-print any stderr/stdout an action produced even if it's inputs haven't changed. Every time I run bazel build //my/target I should see the same output every time. Bazel's job is to optimize out actually needing to rebuild my target, but same inputs should equal same outputs. Right now bazel just isn't conceptually including stderr/stdout as an 'output' from actions, but it is.

This would be highly useful in many cases: looking at compilation warnings, looking at warnings from clang-tidy-as-an-extra-action, looking at test output without needing to bazel clean, etc. It's a really common problem and I'm surprised it's not complained about more.

"The new feature would be to re-print any stderr/stdout an action produced even if it's inputs haven't changed."
How about? bazel build //foo:bar >/tmp/build.log 2>&1

If the inputs don't change, we should not be rebuilding the target, and thus not reproducing old output. That's the point of an incremental build system.

@dapirian : Sounds to me like you should pass -Werror to your c++ compiler if you care about the warnings, I'm not sure caching the warnings makes much sense from Bazel's perspective

Sounds to me like you should pass -Werror

I use -Werror on CI but not for local dev

If the inputs don't change, we should not be rebuilding the target, and thus not reproducing old output. That's the point of an incremental build system.

I'm not requesting that it rebuild the target of course, I'm requesting that it provide me cached outputs of the previous build in the case that the inputs didn't change, where the outputs are both the library it built _and_ the stdout/stderr the commands to build it ran.

Just treat stdout/stderr as one of the outputs of an action. This isn't even specific to compilation at all, it holds true for any action (or "extra action") in the bazel ecosystem

2.2.0 should have --experimental_replay_action_out_err.

Yeah. I didn't realize that there was a GitHub issue for this.

2.2.0 should have --experimental_replay_action_out_err.

This what this ticket is asking for, so I'll close it

Was this page helpful?
0 / 5 - 0 ratings