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
cmake .. -DCMAKE_C_COMPILER=clang \
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
More information about the Mir-devel