Open dkrautha opened 3 years ago
This should actually be pretty easy to do, but it depends on how much detail we really want on our warnings. I have a makefile somewhere that will spit out just about every warning ever, but I doubt we want that level of detail. I'll also look into seeing what flags are enabled by default in debug vs release.
Alright so status update on this! If you add the following to the top level CMakeLists.txt, we get a lot of warnings.
if (MSVC)
# warning level 4 and all warnings as errors
add_compile_options(/W4 /WX)
else()
# lots of warnings and all warnings as errors
add_compile_options(-Wall -Wextra -pedantic -Werror)
endif()
I got that from this StackOverflow post, but I did remove -Werror for testing purposes and then also -pedantic as the pedantic warnings were also coming from GLAD and other external dependencies. I then used this command cmake --build build --clean-first | grep \| | wc -l
to get an estimate of the number of warnings. This works because a warning with GCC/Ninja/CMake seems to have one line with a line number, a pipe character, the offending code, and then another line with a pipe character and an indicator of what part of the line caused the warning. Therefore, the previously mentioned command should counts roughly twice the amount of lines as there are warnings. As of today, there are 4332 lines of warnings in the main branch, meaning that there are probably just over 2100 warnings in the entire codebase. Taking care of all of this is going to be a struggle for sure. I will probably open a separate issue for this.
As for the original request, I'll look at what flags CMake's release mode uses vs their debug mode flags and see if we can get debug mode to have the same warnings.
Apparently the issue here is that CMake disables optimizations by default for debug mode, so its harder for the compiler to tell when things are potentially uninitialized (a common cause of warnings in release mode that we don't see in debug mode). Looking at this, we could probably try enabling -O1
and seeing if that's enough optimization for the compiler to pick up on the fact that something's wrong while not optimizing out variables that we want to look at.
We only get a limited number of warnings when in release mode (using gcc 10). We also see many warnings when compiling with clang, so it might be a good idea to enable these in debug mode for gcc.