Date: Wed, 11 Nov 1998 17:25:45 -0600 (CST) From: Steve Price <sprice@hiwaay.net> To: Satoshi Asami <asami@FreeBSD.ORG> Cc: ports@FreeBSD.ORG, msmith@FreeBSD.ORG Subject: Re: auto ports build script Message-ID: <Pine.OSF.4.02.9811111650380.9547-100000@fly.HiWAAY.net> In-Reply-To: <199811112238.OAA16776@silvia.hip.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 11 Nov 1998, Satoshi Asami wrote: # I'm trying to come up with something that is easily parallelizable. # It's not clear to me how you can do that in perl, although I think we # can use your script (modified) to take care of a single port in the # parallelized world. Yes this would be an easy mod. I'm working on it right now. # Another is that I truly believe the only way to build correct packages # is to always start with an empty /usr/local. The only thing that is in /usr/local right now with my little script is those files that are required to build the current port. Everything else is 'make deinstall'd before the script moves on. # One thing I haven't mentioned yet in this discussion is the existence # of ports that configure themselves and include support for all sorts # of cruft they find. You see all the gunk in the tree that says ".if # defined(PACKAGE_BUILDING) CONFIGURE_ARGS=--disable-foobar"? That's # because when we build packages on a heavily populated machine, there # are stuff that aren't on the porter's machine and we end up shipping a # binary with dependencies which are not covered by @pkgdep. These problems make for the majority of what Justin and I were finding during the last release (excluding all the ELF dead). # In fact, I think our final goal should be to use pmake to parallelize # this between machines. That way, we can guarantee that a dependency # is built before a port that's requiring it, so we can always use # packages. There are currently 746 distinct dependency trees. It should be easy to tweek my little script and provide a frontend for it that created a new process per dependency tree. No need for anything fancy (like pmake) - the script'll do. ;) A quick example if you would allow me. Suppose I have a simple dependency tree like so: A depends on B, B depends on C, and C depends on nothing. If I understand your approach it would go something like this (I've left out a few steps to try and keep it short). 1) build C's package and pkg_delete C 2) pkg_add C, build B's package, pkg_delete B C 3) pkg_add C B, build A's package, pkg_delete A B C The current tact that my little script takes is this: 1) build C's package 2) build B's package 3) build A's package, pkg_delete A B C After it is done with this dependency tree it does the next one until it has covered all of them. Another example of a more complex tree could be: A depends on C, B depends on C, and C is standalone. Your approach would do this: 1) build C's package and pkg_delete C 2) pkg_add C, build A's package, pkg_delete A C 3) pkg_add C, build B's package, pkg_delete B C My little script does this: 1) build C's package 2) build A's package, pkg_delete A 3) build B's package, pkg_delete B C Unless I'm missing something fundamental here, doing the latter in both cases seems to not only do the "same thing", but does it in a more efficient manner. Please tell me how come I can't see the forest for the trees. :) -steve # Satoshi # To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.OSF.4.02.9811111650380.9547-100000>