Is it safe to compile multiple ports at the same time ?

Paul Koch paul.koch at statseeker.com
Wed May 17 06:15:47 UTC 2006


> > So.... it would be nice to have some type of locking in the ports
> > build. For example, when a make enters
> > /usr/ports/{category}/{port}, it gets an exclusive lock on that
> > port (maybe on the Makefile itself, or a specific lock file) before
> > it attempts to build/install the port.  It could be done by using
> > lockf, but that just forks more processes, and there are already
> > lots of them. I'd dare to say.... maybe it could be a function of
> > make itself. As in, extend make so it understands a new keyword
> > that makes it get an exclusive lock, using flock(2).
> >
> > With locking, you should then be able to fire off lots of port
> > builds and use up all those cpu cores :)
>
> Not really, locking will just prevent breakages. Let me illustrate my
> thought with an example:
>
> port A depends on X
> port B depends on X
>
> You start building A which results in building X via exclusive lock
> on X. During the build of X you decide to build B which results in
> building X (X is not yet installed) but you block trying to acquire
> the exclusive lock on X so you wait _idling_ until building of X is
> done. Furthermore what do you suggest to do when the lock is
> released?
>
> Ofcourse if B depends also on Y it can fallback to building Y if it
> cannot gain exclusive lock on X.

Yes, breakage is the main problem.

When the lock is released, then the second make will immediately see 
work/.build_done.XXXXXXX is present ??, then return successfully to the 
make which called it.  I haven't looked to see how it works under the 
hood though.

Yep, in your example above, it won't be any faster.  But what if I want 
to do something like:

 port A depends on  Q R S T X
 port B depends on  D E F G X

then lots of simultaneous building can occur until they both hit port X.

	Paul.



More information about the freebsd-ports mailing list