From owner-freebsd-ports Wed Nov 11 15:26:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA17611 for freebsd-ports-outgoing; Wed, 11 Nov 1998 15:26:21 -0800 (PST) (envelope-from owner-freebsd-ports@FreeBSD.ORG) Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA17603; Wed, 11 Nov 1998 15:26:15 -0800 (PST) (envelope-from sprice@hiwaay.net) Received: from localhost (sprice@localhost) by mail.HiWAAY.net (8.9.0/8.9.0) with SMTP id RAA05070; Wed, 11 Nov 1998 17:25:45 -0600 (CST) Date: Wed, 11 Nov 1998 17:25:45 -0600 (CST) From: Steve Price To: Satoshi Asami cc: ports@FreeBSD.ORG, msmith@FreeBSD.ORG Subject: Re: auto ports build script In-Reply-To: <199811112238.OAA16776@silvia.hip.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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