<div dir="ltr">On 6 February 2013 22:13, Arnaud de Grandmaison <span dir="ltr"><<a href="mailto:arnaud.adegm@gmail.com" target="_blank">arnaud.adegm@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div style="font-family:'Sans Serif';font-size:9pt;font-weight:400;font-style:normal"><div><div class="h5">
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"><span style="font-size:9pt;color:rgb(34,34,34)">I think we just need to increase coverage. Everything you can do to build (even slightly) differently than other bots is good to have.</span></p>
</div></div></div></blockquote><div><br></div><div style>Hi Arnaud,</div><div style><br></div><div style>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...</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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...</div>
<div style><br></div><div style>cheers,</div><div style>--renato</div></div></div></div>