The article that has generated the angry and aggressive comments over the years, normally by e -mail, but also occasionally as Comments on places like Hacker NewsIs -Werror is not your friend.
I have updated this article several times in the past 6 years to tackle some of the joint answers, but it doesn’t seem to do much good. I wanted to go into some comments about Hacker News, but I only noticed that it was shared there after it was too late to answer. Instead of overfilling the original article with side problems, I will address the most common feedback points in this article so that I can show people here.
I can see if you haven’t read the article
The most common feedback comes from people who do not read the article. They see the title and immediately attack me because I am unprofessional and do not take care of warnings. I should be ashamed and adopt for myself -Werror immediately. (This is the polite version).
If you write something like this, it’s just a giveaway that you should not be listened to.
“This is not a problem that companies have to deal with”
Over the years, the next constraint was to tell me that this is not a real problem to do with the company. It only applies to open source projects.
Thinking is that a company usually works with single toolchain and rarely updated to a new version (e.g. once a year). Removal of new warnings will be part of the update efforts. Because of this, -Werror Is safe to use, and I simply create Strohmann arguments so as not to justify this.
For me, this answer is simply a tendency of your own experiences. Everything you tell me is how how Companies you have worked on work. This type of argument is one to which I am used to How many strongly formulated general embedded systems advise, reveals the systems on which the person worked. There is a big big world out there. As difficult as it may be, we have to take into account that our experiences are limited to a tiny problem area and our practices and lessons drawn may not be as widespread as we think.
I worked with dozens of different companies of different sizes, so I saw a wide mix of practices (and yet only a tiny sample of the immense world of software development). Some companies work in the way described above. In other cases, “Never Update” is the name of the game – I still come across teams that use arm-none-eabi-gcc V4.9 to create your project (from October 2023, 12.3 is the latest version). Other companies update toolchains as soon as a new version for use is qualified, most frequently to record safety loans and warning improvements.
The use of several toolchains is completely one thing
The idea that companies will only work with a single toolchain or a version is incorrect. Most of the embedded projects that we used at least two toolchains: one for the target hardware and one for the local build machine (e.g. to create off-tart tests or simulator application).
Even if it is the same provider (e.g. GCC), you probably use a different basis tool. You probably also have different relief cycles and are updated at different times.
The problem can be supported by the need to support several architectures within a single code base (e.g. they build products with AVR, 32-bit arm and 64-bit arm processors) even more complicated. If your company matures and the need to support the desktop tool grows, you may even find firm MSVC as well as.
In other cases, the teams with several toolchains can build up as a cross -test (e.g. GCC and Clang) or receive access to unique analysis functions.
Just update the code when you update the toolchain
Another frequent aspect of this way of thinking is that the Toolchain update will rarely take place in a controlled manner. For this reason, the code base should be updated to fix warnings when the new Toolchain version is introduced.
This is theoretically beautiful, but not always the most important approach in practice.
The team, which drives an update for the build infrastructure, can be separated from the development team and may not be able to properly remedy the new warnings (or that they may be delayed by the development team that defuse such an effort) . Whether this is acceptable depends on many logistical and political factors in your company.
The need for updating can also be driven by more important factors than new warnings, such as: In this case, new warnings do not have to submit the update and can be fixed as soon as the main concern is solved.
You also have to consider that not all changes are equally valuable. There can be a project very well that is simply in maintenance mode, and the company wants to invest as little time as possible in the code. It is an absolutely reasonable strategy to create this code with the latest toolchains as a reason test and at the same time postpone warning fixes into the future.
Another common topic is that there is always A toolchain dependency, it is not just the use of -Werror That introduces it. The correct solution does not avoid -WerrorYou just have to properly record your build environment or create it in containers.
I mention this in the article, so I definitely get annoyed about you.
If you use this flag, make sure you use the version (s) with which your project work with the work (or your build environment fully records).
Yes, the recording of your build environment is a way to solve this problem. Containers are a technological choice and can be right for your company. Do what you want.
The case may also be that you cannot control the software building environment to the extent that you want. If you sell source code or service that depends on an SDK, you can certainly try to say: “This only works with X86_64 GCC 12.3” or “We only support with our approved container to create this”, but reality is that you have to work with the environments that your customers use.
The title is misleading
No, it’s not. I do not support the use -Werror As a build flag that is used by default for your build goals.