clang in jenkins

Daniel van Vugt daniel.van.vugt at
Tue Mar 26 01:46:57 UTC 2013


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.

- Daniel

On 22/03/13 23:55, Martin Mrazik wrote:
> Let me know if you there is a broader agreement on clang.
> If you care there are couple of options we can do --
> 1. run clang build daily
> 2. trigger clang build on trunk everytime there is a change in trunk
> 3. keep clang in ci (but I think alan_g would call that a distraction)
> but remove from autolanding
> ...
> M.
> <mmrazik> btw. there is a clang build enabled in addition
> <alan_g> are we supporting clang?
> <mmrazik> alan_g: is the question "do we care about clang errors" or
> "can we compile lp:mir with clang"?
> <mmrazik> the later is true
> <mmrazik> duflu asked me to have clang job in jenkins earlier today
> <mmrazik> this is what the jenkins job is doing: cmake ..
> <alan_g> mmrazik: the question is "does spending time on clang help
> deliver what we promised"
> <mmrazik> right
> <mmrazik> alan_g: can't answer
> <mmrazik> shall I drop an e-mail to mir-devel ?
> <mmrazik> I thought you guys care given you approved the MP
> <alan_g> AFAIK clang isn't a supported platform (just a nice to have).
> <kdub> alan_g, +1
> <kdub> alf_, re-review of android-display-factory? :)
> <alf_> kdub: on it
> <mmrazik> kdub, alan_g: so you are -1 on clang blocking the ci/autolanding
> <mmrazik> what if I keep it for ci and remove for autolanding? I.e. you
> will be able to merge code even if clang fails
> <alan_g> mmrazik: yep
> <kdub> mmrazik, yes, at least until we figure get our gcc arm compiles
> to a nice point
> <mmrazik> so should I remove clang completely?
> <alan_g> mmrazik: g++ arm is a supported platform
> <mmrazik> shall I translate g++ arm as building natively on arm (like we
> do in ppa)?
> <alan_g> mmrazik: clang shouldn't distract you or us from what we are
> trying to deliver
> * mmrazik is removing the clang job

More information about the Mir-devel mailing list