clang in jenkins
Daniel van Vugt
daniel.van.vugt at canonical.com
Tue Mar 26 09:30:48 UTC 2013
Part of my original request to Martin last week was to ignore the input
stack:
cmake .. -DCMAKE_C_COMPILER=clang \
-DCMAKE_CXX_COMPILER=clang++ \
-DMIR_DISABLE_INPUT=ON
Yes, more work is needed on input to make it clang-friendly (bug
#1157613). But it's not a blocking clang-CI support. We can get most of
the way there right now with -DMIR_DISABLE_INPUT=ON.
On 26/03/13 17:24, Alan Griffiths wrote:
> On 26/03/13 07:26, Daniel van Vugt wrote:
>> 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... ?
>
> I would have no objection to having clang in CI if all that was
> happening is that it detected new errors. But there is more work needed
> than that - and it is the timing of that work that concerns me. I think
> after Daniel's work on clang support that the code we've written is
> pretty close to being clean under clang.
>
> However, the same is not true of the input stack we've forked from
> android - and I don't think we should be trying to clean up that code
> until we have it under automated tests. (FWIW There's other clean-up to
> that code we've also postponed - adding clang to that exercise is
> probably better timing.)
>
> So, while long term I think clang support would be a good thing and I'd
> keep it in the backlog, I don't think it something we should be spending
> time on in the current iteration. (I'd rather we stabilised our arm
> support.)
>
More information about the Mir-devel
mailing list