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. I don't believe Buildbot is capable of such strategy, though. Galina may know of a way of doing this... But I'm ok with just running { warm+ninja } for the foreseeable future... cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130206/94fee31f/attachment.html>
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 >
> -----Original Message----- > From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On > Behalf Of David Blaikie > Sent: 06 February 2013 23:05 > To: Renato Golin > Cc: Clang Dev; LLVM Dev > Subject: Re: [cfe-dev] [LLVMdev] Using CMake/Ninja on buildbots > > ... > > 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.+1. It seems to make sense to me to leave the "make clean" configurations to platforms that can build very quickly from scratch; and for the available arm buildbots to set up builds so that they do incremental builds as quickly as possible. Kristof