clang in jenkins

[Daniel van Vugt]

If you commit code that can't build with clang, that's instantly a bug 
that needs to be logged and fixed later. I would prefer we found out 
about such errors immediately and did not allow them to land in the 
first place.

I guess option 3 does allow for this. As a human can assess the error 
from clang and decide "Needs fixing".


On 26/03/13 10:04, Robert Ancell wrote:
> 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
>>>
>>
>
>