On 19 March 2017 at 12:51, Zbigniew Jędrzejewski-Szmek <zbys...@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. 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. Probably to have this functionality it will be necessary to extend rpm spec syntax to have for example SourceMaintainer: new spec field. Those automatically generated emails may be kind of driving force to relatively quickly remove those warnings on massive scale across whole distribution. 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. Even without above raw build logs preserved on koji enriched but full warnings verbosity has some very big potential. kloczek -- Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
