[48314] trunk/base/src/port1.0/portbuild.tcl

[Ryan Schmidt]

On Mar 21, 2009, at 05:15, Joshua Root wrote:

> Ryan Schmidt wrote:
>> On Mar 18, 2009, at 21:23, Jeremy Lavergne wrote:
>>> When are we going to have the mass ports-upgrade to rid ourselves of
>>> the default values that are going to be there (use_parallel_build
>>> yes)?  Is it going to be scripted or will this be left to the
>>> maintainers?
>>
>> It can't happen until a version of MacPorts with this change is
>> released, which I guess will be 1.8.0. We can discus it after then. A
>> single mass-update by a MacPorts mgr would be fine.
>
> We don't necessarily have to do that. It isn't hurting anything, and
> could serve as documentation that parallel build has been tested.

Uh, true. I have pushed for that myself in the past. Very well, it  
should stay.

With dismay I note my earlier proposal of replacing  
use_parallel_build with build.max_jobs doesn't leave a way to  
indicate that a port works fine with any number of parallel jobs. :-(

Well, it could be two parameters.

build.parallel (values yes or no, default yes) this would be a direct  
equivalent to use_parallel_build (which would be deprecated later)

build.max_jobs (nonzero positive integers, default maxint)


Maybe max_jobs isn't the right name either. Because both the value in  
the portfile and the value in macports.conf are maximums: the former  
is the maximum number of jobs the port supports, and the latter is  
the maximum number of jobs the user wants. The number of jobs that  
will be started is the smaller of the two. Maybe both can be called  
"build.jobs".