clang in jenkins

Martin Mrazik martin.mrazik at canonical.com
Tue Mar 26 07:19:10 UTC 2013


Hi,

On 03/26/2013 02:46 AM, Daniel van Vugt wrote:
> Martin,
> 
> Scanning the code with Clang raises errors that GCC can't find yet (but 
> may be able to in future). They're almost always valid errors too; 
> things we definitely want to fix.
> 
> In the case of eventually running code built with clang; yes it is 
> important for quality. Not for releases, but my experience with multiple 
> projects has been that if code crashes with clang then it definitely 
> needs fixing somewhere.
> 
> In the past I've had the luxury (or misfortune) of having to support 
> half a dozen compilers simultaneously (and a dozen unique platforms). 
> And I always found that adding yet another compiler/platform revealed 
> interesting errors and bugs that the existing compilers did not (even in 
> supposedly mature/stable code).
> 
> Yes, code quality is definitely "delivering on what we promised". And 
> clang is a very easy way for us to raise the quality bar a little 
> higher. If it's not in CI then we will have the pain of periodically 
> someone scanning the code with clang and logging bugs for things that 
> could easily have been detected automatically, and sooner.


Just a short comment given the e-mail is directed to me. I personally
agree, but it is you (i.e. mir-team) who needs to tell me if this is
what you want or not. I don't have enough information to assess this and
it looks like you are not on the same page on how useful clang is.

If you give me a clear "yes, we want this" I'm happy to (re)enable it.
All the work in jenkins has been already done.

Thanks,

Martin
-- 
Martin Mrazik | Product Strategy Quality Lead
Key fingerprint:
0373 C5E5 6A04 39FF 9D06 31B8 B296 2F5D 35FF D83B



More information about the Mir-devel mailing list