Replies: 3 comments 2 replies
-
As I hinted in the post, I claim E3SM should have a warning free build. Compiler warnings are often helpful to me, to spot issues ahead of time. As the number of warnings grows, people are more likely to ignore them, resulting in higher risk of bugs making their way into the main branch. |
Beta Was this translation helpful? Give feedback.
-
Yes because this is the project that cares about good software practice and reducing warnings is part of that. I think all developers should have this as a "background task" but we'd probably need some organized effort to make a dent in current warnings. |
Beta Was this translation helpful? Give feedback.
-
The CI (at least public facing ones like circleCI) should fail with any warning imho |
Beta Was this translation helpful? Give feedback.
-
Building E3SM generates a large amount of warnings. Some are linked to some compilers (e.g., some warnings from cuda compilers are "hard" to get rid of). However, there are a lot of warnings that are reproducible across compilers. They are often benign (e.g., unused variable), but contribute to make it impossible to spot a really concerning warning. In fact, I have long since given up looking at bldlog to see what warnings my code would add, since it would take me too long to parse it.
I am aware that fixing benign warnings may seem like a "style" task, and that "the model works, and we have science questions to answer". Alas, if the compiler warn you, it does so for a reason; even if 1 out of 1000 warnings is a real bug, a code with vast downstream implications such as E3SM should probably guard against it.
3 votes ·
Beta Was this translation helpful? Give feedback.
All reactions