[cfe-dev] [LLVMdev] Using CMake/Ninja on buildbots

[David Blaikie]

On Wed, Feb 6, 2013 at 2:53 PM, Renato Golin <renato.golin at linaro.org> wrote:
> On 6 February 2013 22:13, Arnaud de Grandmaison <arnaud.adegm at gmail.com>
> wrote:
>>
>> I think we just need to increase coverage. Everything you can do to build
>> (even slightly) differently than other bots is good to have.
>
>
> Hi Arnaud,
>
> I agree building with { CMake, autoconf } x { Cold, Warm } will catch more
> corner cases than defaulting all builds to the same standard, however,
> relying on patchy distribution to achieve that is naive. Also, we don't need
> to catch build corner cases on every commit...
>
> A standard build system for buildbots and developers is beneficial because
> you don't need to run around to fix bugs specific to a build system that is
> not often used. The fact that people wanted to remove the MBlaze back-end
> today is for that very reason. Generic changes on other parts demand
> specific changes on a part of the code that is not used often.
>
> That said, it is possible that some of the options we have with autoconf are
> not available on a CMake build (I'm guessing here), and thus deprecating
> autoconf entirely is not an option right now. If the reason is strong enough
> to keep autoconf for the foreseeable future, than we do need coverage.
>
> But coverage means running both CMake and autoconf, both warm and cold, on
> each variant that we care about. So, if that would be true, I'd have to have
> at least 4 buildbot configurations for every ARM platform I care about. For
> now, I care about A9 and A15, so I'd have to have at least 8 bots. How much
> of that I can ignore depends on my interest on them, availability of
> hardware, etc.
>
> Thinking that I can get away and have { warm+autoconf on A9 } + { cold+ninja
> on A15 } and saving 6 bots is naive, at best. However, having { warm+ninja }
> on both and, during weekends doing one of each { warm+autoconf }, {
> cold+ninja } and { cold+autoconf } on the same commit, then continuing with
> the bot schedule, would at least give you a uniform, but not precise, view
> of the build system failures. The three additional builds will rarely give
> you real code errors, so it's ok to be only once a week.

You're right - it's a tradeoff & I think in favor of not wasting
resources validating all the different build tools on every commit. If
there are bugs in the warm builds of Ninja I think it's better to fix
those than to run clean builds - we should have immense confidence in
incremental rebuilds or we're going to be much slower as developers.

Especially for these slower hardware platforms it's much more
important to diagnose the more likely bugs (actual problems that only
arise on this hardware - since it's also hardware that is going to be
very infrequently run by the general developer community pre-commit)
and do so as fast (& with as small of a commit/blame range) as
possible.

> I don't believe Buildbot is capable of such strategy, though.

http://buildbot.net/buildbot/docs/0.8.0/Nightly-Scheduler.html#Nightly-Scheduler

>  Galina may
> know of a way of doing this... But I'm ok with just running { warm+ninja }
> for the foreseeable future...
>
> cheers,
> --renato
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>