On Sun, Mar 19, 2017 at 03:09:59PM +0000, Tomasz Kłoczko wrote:
On 19 March 2017 at 12:51, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl>
wrote:
> No. There's a policy to show the full command line option, but that's not
> the same. Most warnings are only useful for upstream developers, and
> packagers are not (and should not) do anything about them. One obvious
> case is unused variables and functions, especially in generated code.
> Another is stylistic variations for old but valid code. Yet another could
> be the new fall-through warnings in switch statements. Etc, etc.
>
Verbosity of the visibility command line params it is different story and
it has nothing to do with what I've suggested.
As I wrote it has potentially very useful case to have maximum level
reporting compile errors on distribution level.
koji could parse build logs and count total number of compile time warning
and in own build report put that in release N it was more/less such
warnings than in Release N-1.
I think the S/N ratio would be very low here. In
previous mail I
listed various classes of warnings which are best ignored. If you want
to fix things, go project by project and submit patches upstream.
Don't force it on all maintainers.
In case introduction of new gcc with which may start reporting new
warnings
full verbosity of the compile warning will allow "in combat" asses impact
reporting these warnings on whole distribution scale.
With source tree maintainers email addresses in some database it may be
even possible to sent automatic report to these maintainers about those
warnings.
No thank you, but no.
gcc can now load some extensions as DSOs and maybe it would be
possible to
use this entry point to start thinking about develop extension which would
allow store formated data about types and locations of warning in some text
file per package which will be easier to parse and process. Parsing raw gcc
stderr output may be not so useful in such case.
D.Malcolm's gcc-python-plugin
had some support for machine readable output.
See also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165
https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Message-Formatting-Options....
Zbyszek