750381 - Enable warnings-as-errors by default for well-known compiler/platform configs

Status: RESOLVED WONTFIX

(Firefox Build System :: General, defect)

Description

[Jason Duell]

I think we should turn on WARNINGS_AS_FAIL for well-known configs (gcc on linux, MSVC on windows, etc.), as it avoids 1) the cost of needing to educate developers that they have to pass --enable-warnings-as-errors (I just spent some time figuring that out), and 2) the cost of bot builds burning from warnings devs would have seen on their local compile were this the default.

If warnings vary a lot by gcc version, etc. then we should turn it on only for compiler versions we care about.  But I'm guessing we could get fairly wide developer coverage by default.

Thoughts?

Comment 1

[(not currently active) Ted Mielczarek]

We have been down this path before, and it's always a trail of tears. You're welcome to try again, certainly.

Comment 2

[Daniel Holbert [:dholbert]]

I don't think we want to impose this on local builds by default, for the reasons that dbaron laid out here:
 https://groups.google.com/d/msg/mozilla.dev.platform/ZD6UT3XjuuQ/EFN8KoHW-KUJ

In particular (quoting that post):
> We don't want to scare off new contributors with build errors that
> happen the first time they try to build Mozilla, and which require a
> weird .mozconfig incantation to fix.
.,.and...
> we don't want everybody wasting time when they pull mozilla-central
> Monday morning and have to fight with new build errors.

Given that we only continuously test a select few compilers/versions, I fear we'd be unable to prevent the above issues.

...unless we whitelist, "compiler versions we care about", as you suggest.  But I'd argue that the only sane whitelist would be "the ones that our build machines use", because we can't automatically catch new build-failures that crop up in any other versions.  So that whitelist would be very small, and I suspect the number of people who actually use a compiler version from that list would be pretty small as well (since our builders tend to pick a stable compiler release & stay there for a while, while developers move on to the latest and greatest).  So in practice, a whitelisting strategy wouldn't have much of an effect at all.

So, I don't think this is really worth it... I think we're better off encouraging people to use Try Server and/or opt themselves in to --enable-warnings-as-errors locally.

Comment 3

[Jason Duell]

OK then.

Comment 4

[Nicholas Nethercote [inactive]]

> ...unless we whitelist, "compiler versions we care about", as you suggest. 
> But I'd argue that the only sane whitelist would be "the ones that our build
> machines use", because we can't automatically catch new build-failures that
> crop up in any other versions.  So that whitelist would be very small, and I
> suspect the number of people who actually use a compiler version from that
> list would be pretty small as well (since our builders tend to pick a stable
> compiler release & stay there for a while, while developers move on to the
> latest and greatest).  So in practice, a whitelisting strategy wouldn't have
> much of an effect at all.

I'm as much of a warnings-as-errors partisan as anyone... and I agree this is the right compromise.