Finding Mistakes
Let's learn about configuration errors, configuration warnings, and debugging issues.
As programmers, we spend a lot of time bug hunting. It's a sad fact. Finding errors and solving them can often get under our skin, especially if it takes long hours. It's even more difficult when we are flying blind, without instruments to help us navigate through the storm. This is why we should apply great care to set our environment in a way that makes this process as easy and as bearable as possible. We do this by configuring the compiler with target_compile_options(). Which compile options could help us then?
Configuring errors and warnings
There are many great stressful things about software development: fixing critical bugs in the middle of the night, working on high-visibility, costly failures in large systems, and dealing with annoying compilation errors, especially those that are hard to understand or impossibly tedious to fix. When researching a subject in order to simplify our work and reduce the chance of failure, we'll find a lot of recommendations on how to configure the compiler's warnings.
The -Werror flag
One such fine piece of advice is to enable the -Werror flag as default for all builds. What this flag does is innocently simple—all warnings are treated as errors, and the code won’t compile unless we resolve all of them. While it may seem like a good idea, it hardly ever is.
Warnings aren’t errors for a reason. They’re meant to warn us about things. It’s up to us to decide what to do about that. Having the freedom to ignore a warning, especially when we experiment with and prototype our solution, is often a blessing.
On the other hand, if we have a perfect, no-warnings, all-shiny piece of code, it's a shame to allow future changes to ruin this state of things. What harm could come from enabling it and just keeping it there? Seemingly none. At least until our compiler gets upgraded, that is. New versions of compilers tend to be stricter about deprecated features or just get better about ...