By Petr Zemek (15. August 2007, 21:34:57)
Re: compilation.py feedback
 (2 )

Hi Peter,

I guess you rather intended to use it regularly as part of your own development, in which case filtering ONLY excluded warnings and related non-warning lines would be better. I think that the latter use scenario would be more difficult to implement. If you agree, let us optimize the script for the former scenario - occasional runs to verify code quality and standards conformance.

Yes, I’ve been using it as a part of my development. But I’m ok with the variant that you’ve suggested (implementing the former scenario first) - I can then (after it will work perfectly) extend it to handle both situations by adding another script option.

Final question, what is the following regexp for?

.*generators.*
Maybe it’s to exclude 3rdParty/moc/generators… should we exclude everything from 3rdParty instead?

This regexp is actually meant to remove only this “single” warning:

generators/mac/pbuilder_pbx.cpp: In constructor ‘ProjectBuilderSources::ProjectBuilderSources(const QString&, bool, const QString&, const QString&, bool)’:
generators/mac/pbuilder_pbx.cpp:393: warning: ‘ProjectBuilderSources::compiler’ will be initialized after
generators/mac/pbuilder_pbx.cpp:392: warning: ‘bool ProjectBuilderSources::object_output’
generators/mac/pbuilder_pbx.cpp:420: warning: when initialized here

Regards,

Petr

Would you like to post a relpy?


This post is a reply to:
By Peter Dimov (15. August 2007, 21:24:41)
Re: compilation.py feedback
 (3)
Hi Petr, Thanks for the comments! I think that only warnings are printed, but errors are not (this will require just updating the isWarningRegexp regexp, or adding some other regexp that (more...)

Follow-ups:
By Peter Dimov (15. August 2007, 22:18:41)
Re: compilation.py feedback
 (1)
Hi Petr, Yes, I’ve been using it as a part of my development. But I’m ok with the variant that you’ve suggested (implementing the former scenario first) - I can then (more...)