clang in jenkins

Robert Ancell robert.ancell at canonical.com
Tue Mar 26 02:04:57 UTC 2013


I'm also -1 on requiring clang for landing - we shouldn't block on clang
generating errors. GCC/Ubuntu are our platforms and anything else at the
time is a bonus.

I do vote a +1 for option 3 below. If Jenkins could say "approved but
has clang errors" then that would be a useful indicator of future problems.

--Robert

On 26/03/13 14:46, 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.
>
> - Daniel
>
>
> On 22/03/13 23:55, Martin Mrazik wrote:
>> FYI
>>
>> 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 ..
>> -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 mailing list