I like the overall approach.
We can then attack the warnings lib by lib and/or platform by platform.
I do want to mention that some libs like liblcms are 3rd party open
source libraries
and it may not always be possible to convince upstream to change their code.
-phil.
On 03/04/2015 08:30 AM, Alan Bateman wrote:
On 04/03/2015 15:03, Magnus Ihse Bursie wrote:
I believe all warnings are important to check! Unfortunately, this
has not been done for a lot of warnings for a lot of time. :(
Right, although in the past we had some areas close to be cleared of
warnings, it's just that we didn't keep up the effort and of course
the compilers get more pedantic with each version.
With this framework, it is simple to enable a single warning,
recompile and see the effect. Hopefully this lowers the threshold far
enough so that all warnings are given proper attention. The
incremental build functionality will come in very handy. Just by
simply removing a warning from the DISABLED_WARNINGS_<toolchain> on a
library and running "make" again, only the files affected will be
recompiled.
Yes, it looks easy to maintain.
I can easily paste in what warning categories are disabled for a
specific library, yes.
However, if you are asking me to build each library, individually,
with warnings re-enabled, and pasting the output, I'd rather not.
That would be a lot of work, to detangle the output of each
individual library.
I'm not asking that, it would be too much work. Maybe it's worth
saving the logs somewhere so that you can point the bugs at it. It
would also be useful for the bugs to point to your change sets (when
they are pushed) so that it's obvious which make files were changed to
silence the warnings.
-Alan
