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