On Mar 18, 2009, at 21:23, Jeremy Lavergne wrote:
On Mar 18, 2009, at 10:10 PM, [email protected] 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.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
