there's no need for a separate step: show-prepare-results should be
practically instantaneous, and if there's noise, prepare will exit(1)
anyways.
just need to explicitly log the output of prepare.
- the grabber passes them to PortBuilder
... which builds a hash of pkgnames
... and the port uninstall job excludes these from the list of ports to
junk.
Note this only works with -current pkg_delete, as I had to tell it to
ignore non-existent pkgnames in that context
So explicitly close what it will have problems tracking...
problem noticed by sthen@, obviously linked to my previous change to
avoid opening the same log file again and again...
don't blindly append to history, but recreate it from scratch.
We need to remove lines corresponding to stuff that vanished at some
point but came back later!
elsewhere. Also use it for the Reporter, as it makes no sense to spend
THAT much time reporting quick changes, which actually slows the build.
($factor to tweak as needed).
while dependencies are missing
Following landry's remark, also take packages to build out of the race
if some RUN_DEPENDS are going to be ignored. Only do it right before we
put the package in the queue, so that the test is run exactly once per
package instead of during every scan.
I was also worried about multi-packages, but this only takes one fullpkgpath
out of the loop, and "make package" is going to fail half-way through anyways.
happening while some 'unjunk' ports are building.
this is a work-around for a known problem with cmake and qt4 include
dependency handlers...
Also, cache fullpkgpath while building a job, as this contributes for
a large part to the speed (not) of the display when building lots of
ports.
Yields more accurate stat output, where we can see a staircase effect on
the queue when the engine is run not that often, and Built actually go
up until it goes back down again.
duh. put "live" affinity markers while we're building stuff.
We don't re-read the on-disk markers outside of restart (should we ?)
so they HAVE to be in the pkgpath struct proper.
tweak the algorithm slightly (since we forget the old check_interval).
In particular, never keep old times in reserve.
Makes for simpler and clearer reading
Most things will move as a result of {install} changes.
Things that move because of EXTRA depends that are satisfied are unlikely to trigger
further changes.
So, stagger changes for "normal" tobuild -> queue first, and extra depends later.
