On Thu, 15 Dec 2005, Dieter Baron wrote:

> : (There is that other idea to build pkgsrc packages in parallel which is
> : stuck to some people's head, but it grossly violates the KISS principle
> : and involves all sort of nasty things like locking and whatnot; I still
> : suggest not going there)
>
>  We need locking even if we do not build dependencies in parallel:
> Users can invoke multiple makes simultaneously in the same pkgsrc
> tree.

 	Making -j work involves testing and maintaining every package
 	for which we want to enable -j, with the inevitable breakage
 	when someone without an MP box updates a package to a newer
 	version. Making pkgsrc able to build mulitiple packages in
 	parallel 'only' involves making the pkgsrc infrastructure
 	get it right and will work for all packages.

 	Obviously both would be nice - if someone _just_ wants perl or
 	kde3 then there are points where there will only be one
 	(relatively large) package available to build, but the -j
 	is probably best targetted at specific packages, or picking up
 	if its defined in autoconf.

 	Locking is definitely something we want. Once we have that
 	'all' we need is a list of dependencies (tsort) for a given
 	build, and a mechanism for pulling the first one off the
 	list which is not blocked by an active build. It may even
 	be worth adding a new pkg_ tool to manage that part of it.

 	So... until someone implements locking the across package
 	parallel build is moot :)
-- 
 		David/absolute       -- www.NetBSD.org: No hype required --