Am 15.03.2011 23:44, schrieb Chuck Swiger:
On Mar 15, 2011, at 3:35 PM, Eitan Adler wrote:
[ ... ]
Yes. Ports which support parallel builds will have MAKE_JOBS_SAFE=yes set in
the port Makefile. It defaults to running -j with MAKE_JOBS_NUMBER=`${SYSCTL}
-n kern.smp.cpus`, but you can change that to some other # if you like.
No, this is incorrect. The MAKE_JOBS_NUMBER and MAKE_JOBS_SAFE is used
internally when building a single port.
What is incorrect?
When the OP is asking if he can manually specify -j on the command line which
would end up
building multiple ports in parallel. This can not be done (primarily
because there is no locking done on ports)
It certainly wasn't clear to me that this is what the OP meant. If you:
cd /usr/ports/www/apache22
make -j 3
make FORCE_MAKE_JOBS=yes
and the -j argument will default to the number of CPU cores as provided
by the corresponding sysctl. If the port breaks with
FORCE_MAKE_JOBS=yes please file a PR with a patch fixing it, or if that
is too much of an effort, a patch to add a line "MAKE_JOBS_UNSAFE= yes"
(on a single line with a TAB between MAKE_JOBS_UNSAFE= and yes).
...what do you expect to happen, and how many ports would you expect to be
built at once?
(Building one port in parallel is supported, where the port itself is safe to
do so; building many at the same time is not. Supporting the former provides
more speed gain for many situations as compared to the latter; which doesn't
help at all if you are just installing or updating one port.)
I beg to differ on the speed assertion. I own a somewhat fast computer
(Phenom II X4 i. e. 4 x 2.5 GHz) and I find that a lot of serialization
takes place, particularly behind the configure phases and the
mtree/registration stuff.
In that respect, building non-dependent ports in parallel would be
rather useful to actually exploit SMP computers; however it would
require a dependency analysis so that only those ports build in parallel
that do not depend on one another, and I also fear that sometimes mtree
during installation might get in the way.
I seem to recall that Doug stated something to the extent he wouldn't be
doing it in portmaster, and I don't see any other tool that is similarly
mature so it would be worthwhile even trying that.
Best
--
Matthias Andree
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
