Just as a side note regarding static code analysis: we already have integrated a static code checker (CppCheck), and as nha writes, it slows down the build, so it is not active on default but can be activated with a specific cmake parameter (-DWL_EXTRAWARNINGS=on) along with a few altered compiler warning flags. But, also as nha writes, it is being forgotten/ignored long time...
By the way, the cppcheck people often change their command line parameters so the current settings done by widelands are not working with the current version of cppcheck. We could however enable *all* warnings, which creates lots of noise.
Regarding the topic making widelands clang compatible: +1 as it is most probably the future. However, I don't know if clang 2.9 is worth the effort? I'm not deep enough into that topic, but clang 3.0 is completely different (if I can believe what people write about it), so to be future safe, concentrating on clang 3.0 should be enough, I guess.
Just as a side note regarding static code analysis: we already have integrated a static code checker (CppCheck), and as nha writes, it slows down the build, so it is not active on default but can be activated with a specific cmake parameter (-DWL_EXTRAWARN INGS=on) along with a few altered compiler warning flags. But, also as nha writes, it is being forgotten/ignored long time...
By the way, the cppcheck people often change their command line parameters so the current settings done by widelands are not working with the current version of cppcheck. We could however enable *all* warnings, which creates lots of noise.
Regarding the topic making widelands clang compatible: +1 as it is most probably the future. However, I don't know if clang 2.9 is worth the effort? I'm not deep enough into that topic, but clang 3.0 is completely different (if I can believe what people write about it), so to be future safe, concentrating on clang 3.0 should be enough, I guess.