4 ms·

werror is absolutely your friend. The examples given in the article are borderline strawmen. Changing toolchains is a very rare occurrence because the subtle d

werror is absolutely your friend. The examples given in the article are borderline strawmen. Changing toolchains is a very rare occurrence because the subtle differences will almost always cause problems. When someone suggests changing toolchains, they owe everyone a VERY CONVINCING argument. After which the changed warnings will be the LEAST of your problems as you migrate. Toolchain upgrades will cause new warnings to surface as the detection gets better. But you DO want to fix them, don't you? You ARE a professional, aren't you? You DO care about your product's quality, don't you? After over a decade without werror, followed by a decade with werror, I'd take werror every time. Warnings exist for a reason, and in the case of C compilers, VERY GOOD reasons that you really should address. At my workplace, we use werror, static analysis, various lints, detekt... everything that can issue warnings about your code quality. If any of them complain, you can't merge your PR, because we're professionals.

pasc1878 3y ago
In the 1990s I think it was recommended for at least C++ to use at least two different compilers to catch as many errors as possible or to get a more understandable error message. linters and staic anaylsis did not really exist then
tobias3 3y ago
You can do that if you have full control over the toolchain. For example I ran into this issue with the AWS C++ SDK ( https://github.com/aws/aws-sdk-cpp/ https://github.com/aws/aws-sdk-cpp/ ). And then I had to go into several CMake files and remove Werror. What do I as a user care about warnings? Can I only use that SDK once I have fixed (probably more like silenced) all the warnings? At least they added a option now after a few years of this annoyance: https://github.com/aws/aws-sdk-cpp/issues/2555 https://github.com/aws/aws-sdk-cpp/issues/2555
skybrian 3y ago
I’m guessing you haven’t been in a situation where the problems are apparent? Your advice probably works fine for small projects. You can upgrade the toolchain and fix all the new warnings in the same commit. Often there’s nothing to do. It doesn’t work for a monorepo where the toolchain needs to be upgraded for many projects at once. Enabling each new warning (turning it into a build-breaking error) may require touching hundreds of files. Getting a toolchain upgrade done in one monster commit doesn’t work; you will inevitably break something and have to roll back, or be unable to commit it all due to merge conflicts with other commits. I’ve been on a team that needed to be able to upgrade the toolchain in one commit and then turn on each new warning in separate commits. Having an explicit list of all the warnings that are turned on and then gradually updating it to be the equivalent of -Wall was the way to go.
- kstenerud 3y ago
  Yes, I've done that too. The point is, you do it. werror stays on and you just deal with the migrations because you care about your code quality. werror is your friend.
dagmx 3y ago
The author specifically mentions open source projects which is one area where changing tool chains is incredibly common. From different platforms to users having very different versions of a compiler.

pasc1878 3y ago

In the 1990s I think it was recommended for at least C++ to use at least two different compilers to catch as many errors as possible or to get a more understandable error message. linters and staic anaylsis did not really exist then

tobias3 3y ago

You can do that if you have full control over the toolchain. For example I ran into this issue with the AWS C++ SDK ( https://github.com/aws/aws-sdk-cpp/ https://github.com/aws/aws-sdk-cpp/ ). And then I had to go into several CMake files and remove Werror. What do I as a user care about warnings? Can I only use that SDK once I have fixed (probably more like silenced) all the warnings? At least they added a option now after a few years of this annoyance: https://github.com/aws/aws-sdk-cpp/issues/2555 https://github.com/aws/aws-sdk-cpp/issues/2555

skybrian 3y ago

I’m guessing you haven’t been in a situation where the problems are apparent? Your advice probably works fine for small projects. You can upgrade the toolchain and fix all the new warnings in the same commit. Often there’s nothing to do. It doesn’t work for a monorepo where the toolchain needs to be upgraded for many projects at once. Enabling each new warning (turning it into a build-breaking error) may require touching hundreds of files. Getting a toolchain upgrade done in one monster commit doesn’t work; you will inevitably break something and have to roll back, or be unable to commit it all due to merge conflicts with other commits. I’ve been on a team that needed to be able to upgrade the toolchain in one commit and then turn on each new warning in separate commits. Having an explicit list of all the warnings that are turned on and then gradually updating it to be the equivalent of -Wall was the way to go.

kstenerud 3y ago
Yes, I've done that too. The point is, you do it. werror stays on and you just deal with the migrations because you care about your code quality. werror is your friend.

dagmx 3y ago

The author specifically mentions open source projects which is one area where changing tool chains is incredibly common. From different platforms to users having very different versions of a compiler.