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

[Ryan Schmidt]

On Mar 18, 2009, at 21:23, Jeremy Lavergne wrote:

> On Mar 18, 2009, at 10:10 PM, jmr at macports.org wrote:
>
>> Make parallel build opt-out rather than opt-in (buildmakejobs  
>> still defaults to 1)

Joshua, can you add something to the ChangeLog about this change?

> 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.


On Mar 18, 2009, at 21:26, Jeremy Lavergne wrote:

> Curiously, why did we not (or have not yet) decided to use  
> build.parallel to follow what seems to be a build.X pattern?

I don't know.

> Can build.jobs not take its place?

Well, build.jobs is set by MacPorts base and is influenced by  
macports.conf, so you can either set build.jobs in macports.conf to a  
number of jobs you want, or you can set it to 0 to have MacPorts use  
the number of available cores.

I would prefer to delete use_parallel_build and replace it with a  
setting like build.max_jobs which would default to build.jobs (or to  
maxint or some large number). This way, individual ports can set  
build.max_jobs to 1 if they do not support parallel build, or set it  
to some higher value if they are known to be able to build in  
parallel with, say, 2 parallel jobs but are known to fail with 3 or  
more.

We could leave use_parallel_build around for a version or two and  
just mark it deprecated, using the newly-revived option deprecation  
feature.