On 11/26/2011 01:14 AM, Jonathan Nieder wrote: > Hi, > > You wrote[1]: > >> If you have ideas for warnings/diagnostics visibile in buildd logs >> that are worth having listed in a view like that, please let me >> know. > > I'm not sure how your infrastructure copes with something like this, > but I would find it useful to have gcc 4.6's machine-parsable warnings > in such a list. They look like this: > > ../../src/gcc/graphite.c:59:29: warning: non-local variable > 'cloog_pointers__' with anonymous type is questionable in C++ [-Wc++-compat] > > I guess a regex like "\[-W[-+=a-z0-9]*\]" would do, plus > "\[-pedantic\]" and "\[-fpermissive\]".. > > I suppose these could all be lumped as one diagnostic type, except > that when new gcc releases introduce new warnings (like the recent > -Wunused-but-set-variable and -Wunused-but-set-parameter), they could > get a different tag. What do you think? > > Thanks very much for this work, > Jonathan > > [1] https://buildd.debian.org/~brlink/
The first issue with this kind of approach is that not all build logs are verbose by default. So a first step would be to decide if you have a verbose build log, or some quiet mess, and submit bug reports for the latter (there is a lintian report for this, although the lintian maintainers think this is not the right place). It would be good not to limit this to warnings only. Another use case is the check if build flags are really passed to the upstream build system; this seems to be a requisite to the hardening release goal, because you generally can't see for every object in the resulting binary if it was built with or without hardening defaults. So, a more general approach might be more useful in terms for the wheezy release. Matthias -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ed0fcb6.7080...@debian.org