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@xxxxxxxxx> > 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.html#index-fdiagnostics-parseable-fixits Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
