On Tue, Mar 20, 2012 at 08:58:45AM -0700, Brendan Conoboy wrote:
On 03/20/2012 08:24 AM, Jakub Jelinek wrote:
>I think the speed of the build hardware should be also part of the criteria,
>as all primary architectures are built synchronously. GCC on x86_64/i686
>currently builds often in 2 hours, sometimes in 4 hours if a slower or more
>busy box is chosen, but on ARM it regularly builds 2 days. That is a slow
>down factor of 12x-24x, guess for other larger packages it is similar.
Our current build systems can turn GCC 4.7 around in about 24 hours.
The enterprise hardware we anticipate using will take that down to
about 12 hours. If speed of build hardware is a consideration,
where do you draw the line? No secondary arch is going to get to
the speed of x86_64 in the foreseeable future, so it's effectively a
way to keep PA an exclusive x86 club.
Looking at last gcc build times (not unusual, though I really remember
arm taking much longer than that, e.g. 4.7.0-0.11.fc17 took almost 17 hours
on both arm architectures), from
So even speeding this up twice means it is still 2x slower than the
slowest other secondary architecture.
I think the real question is, for the developers of on devel-list,
how will longer builds for one arch than another affect your
workflow? If builds on two architectures start at the same time,
but one takes longer to finish than the other, how will that impact
you? Right now you'll still be able to see and use the results of
the faster build before the slower build completes, so are you
For the builds completed on some architectures, but waiting on others
nothing is moved over to the packages/ dirs. Yes, you can grab them
from the task directories, but only manually, scripts fetching testsuite
results won't see them, it can't be filed into bodhi, in rawhide isn't
tagged into the buildroots, etc.