Date: Wed, 11 Nov 1998 15:40:06 -0800 (PST) From: asami@FreeBSD.ORG (Satoshi Asami) To: sprice@hiwaay.net Cc: ports@FreeBSD.ORG, msmith@FreeBSD.ORG Subject: Re: auto ports build script Message-ID: <199811112340.PAA17073@silvia.hip.berkeley.edu> In-Reply-To: <Pine.OSF.4.02.9811111650380.9547-100000@fly.HiWAAY.net> (message from Steve Price on Wed, 11 Nov 1998 17:25:45 -0600 (CST))
next in thread | previous in thread | raw e-mail | index | archive | help
* 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. Oh, ok. * # 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 * These problems make for the majority of what Justin and I * were finding during the last release (excluding all the ELF * dead). You were actually finding those? Wow. * 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. ;) The problem here is that dependencies are not trees. What we have is an directed acyclic graph (DAG). You can't guarantee ordering on DAG's unless you wait for completions of some processes, which a shell "&" won't do while make does. * 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 * 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. This is nice, but what do you do if there is another port, D, that depends on B? You don't have to wait for 3 to complete to start the build of D, you only need 2. * 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 Note 2 and 3 can be done in parallel. * 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. :) It's surely more efficient on one machine, but I'm just not sure how well it parallelizes. :) 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?199811112340.PAA17073>