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