clang in jenkins
Daniel van Vugt
daniel.van.vugt at canonical.com
Tue Mar 26 07:26:35 UTC 2013
You'd be hard-pressed to find a good argument against automated static
analysis. It's always useful to improve code quality from more angles.
I believe Alan's concern was that we were devoting resources to the
effort that we couldn't spare... ?
On 26/03/13 15:19, Martin Mrazik wrote:
> On 03/26/2013 02:46 AM, Daniel van Vugt wrote:
>> 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.
More information about the Mir-devel