portinstall breaks with -m "-j 4"
LoN_Kamikaze at gmx.de
Mon Jul 24 10:33:11 UTC 2006
> 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
That's a good idea. I'll try to make a small patch for this.
More information about the freebsd-ports