Compiler warnings are a tool we enable as developers to detect
issues with our source code that go beyond the basic requirements
of compiling C++ code. For example, many implicit conversions are
perfectly correct, and defined behavior in C++ but we choose to
disallow them with -Wconversion. This is something only us devs
have to care about. Someone using SFML wants the library to work
well but does not need to concern themselves with such low level
details about its implementation.
By disabling warnings in non-developer builds, we ensure that non-
developer users of SFML are not going to see console noise due to
warnings and it prevents issues like GCC's bug 82952 which causes
compilation to halt indefitely due to a bug in how a compiler
warning is implemented.
This also improves compatibility with older compilers. If we enable
warnings in all builds no matter what, we have to protect against
compilers we don't expect. Perhaps someone uses an older version
of GCC that we haven't tested with. This compiler is perfectly fine
compiling our C++ but we happen to use a warning flag it does not
recognize so the build fails. This is not a good reason for a
build to fail but nevertheless it's something we have to deal with
so long as we always enable warnings.
SFML_WARNINGS_AS_ERRORS is now named somewhat incorrectly but I
retained the name for compatibility's sake. We can rename it to
SFML_ENABLE_WARNINGS or something similar in SFML 4.
CMake supports a number of strings for truthy and falsey values.
ON/OFF and TRUE/FALSE are the most popular but 1/0 is also supported.
This is mostly a style choice but I'm inclined to believe that ON/OFF
is the most popular option and I'm generally in favor of style
choices that better align with the community at large.
This is not the best default value because it imposes additional
requirements on user builds that are not strictly necessary. This
has caused many complaints in the past as people encounter build
failures that are merely due to warnings and not hard compiler
errors.
Changing this default value emakes it more likely that someone trying
to use SFML can use it without issue.
The use of target_compile_options makes it easy to append warnings
to a target. The use of generator expressions also more succinctly
handles a few edge cases for compiler bugs and platform-specific
oddities.
This should be easy to read and maintain than the variable-based
solution it replaces.
