On Saturday 22 July 2006 22:13, Mark Linimon wrote: > > BTW, I apologize for this is not at all a portupgrade issue, but an issue > > of the ports system. > > It is an issue with individual ports -- actually not the "port" (e.g. > Makefile framework, pkg-*) but the individual applications (IIUC). > > > Well, at least the ports system itself should not be broken able to work > > with this. With larger ports I manage to reduce build times by 40% with > > distcc and a second machine. As far as I see it the number of ports > > breaking is rather low. > > Please feel free to suggest a framework (complete with regression test > framework) where the infrastructure code can "learn" which ports are safe. > I think it's going to be a harder problem than you think it is. Note that > "appears to work" and "can be shown to work under arbitrary build > circumstances for all users" are IMHO going to be two very different > classes of problem -- and the latter will need to be solved before it > can be used on the package-building cluster.
It seem to me that virutally all the advantage could be obtained by passing -j just to the build stage, where portupgrade spend most of its time. In any case install is probably too IO-bound to benefit. The user could set say WITH_PARALLEL=4. The value could be passed down to the build if the port sets USE_PARALLEL=yes or the user sets WITH_PARALLEL_FORCE=yes. _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
