clang in jenkins
Daniel van Vugt
daniel.van.vugt at canonical.com
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.
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
> <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 ..
> -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DMIR_DISABLE_INPUT=ON
> <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