To first order builds are done on a first-committed-first-built basis.
The time a build takes is not something known up front so prioritizing
basis on this would anyway not really be feasible.
Yes, the builders must install the dependencies of a port before a given
port can be built. If one of those deps also has an update in the queue,
later on than the current build, but needed for the build then it will
be done 'early'. so in a sense it is correct that commonly used
dependencies will tend to get built a bit faster than they might
otherwise get done.
'Normally' though the builders keep up with the pace of commits, so the
build queue is reasonable short. It can happen that some commit might
happen that requires a lot of ports to get built, or a big build (like
gcc, clang or rust) comes along that causes a small backlog to build up.
These are usually cleared quite quickly (by which I mean a few days).
Another cause of a backlog is when a new builder is added, like was done
recently for macOS12. The builders in this case have to work their way
through all the various deps, so a backlog can build up that takes a
while to clear.
Chris
On 29/11/2021 2:32 pm, Richard L. Hamilton wrote:
I would expect that the buildbots also need to satisfy dependencies, and
thus, heavily-depended on builds would tend to be done earlier,
regardless of whether or not they were large and slow; and if they are
large and slow, they're arguably delaying the building of even more
smaller ports that don't depend on them, which is not necessarily a gain.
If I'm right about ports being built also by the buildbots in dependency
order, any further tweak to build order would likely have minimal benefits.
The real improvement would be more buildbots, but that would take either
a way of trusting volunteer buildbots (and that they were managed
properly to produce fully correct results, and quite possibly dedicated
to the purpose to avoid anything that would conflict or interfere), or
an actual budget, or donated servers and server farm space, power,
cooling, etc. Another improvement might be more people qualified,
trusted, and authorized to babysit the buildbots, and/or automatic
tickets on failed builds, since if a build on a buildbot fails, it's
either a problem with the buildbot or with the port itself; and in the
latter case, those building themselves will also have the problem.
On Nov 29, 2021, at 09:15, Bill Cole
<macportsusers-20171...@billmail.scconsult.com
<mailto:macportsusers-20171...@billmail.scconsult.com>> wrote:
On 2021-11-29 at 08:32:46 UTC-0500 (Mon, 29 Nov 2021 13:32:46 +0000)
Chris Jones <jon...@hep.phy.cam.ac.uk <mailto:jon...@hep.phy.cam.ac.uk>>
is rumored to have said:
If you find yourself during an port update building rust from source,
either just let it finish, or if you don't want your machine tied up
building rust for some period, just cancel the build and try again
later on, as as others have pointed out eventually the buildbots will
provide the binary tarball for it and thus you will just pick that
once its available.
This raises a question that I cannot find a clear answer to:
How are builds prioritized on the buildbots?
I would hope that in an ideal world, some priority is given to large,
slow, and heavily-depended-upon builds. It's also easier to say that
than to actually implement it, but it would help address a real pain
point in using MacPorts.
--
Bill Cole
b...@scconsult.com <mailto:b...@scconsult.com> or billc...@apache.org
<mailto:billc...@apache.org>
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
--
eMail:mailto:rlha...@smart.net <mailto:rlha...@smart.net>
