Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com List-Subscribe: List-Archive: List-Post: List-Help: , Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com Message-ID: <3C061994.4020407@ece.gatech.edu> Date: Thu, 29 Nov 2001 06:18:44 -0500 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Robert Collins CC: cygwin-apps AT sources DOT redhat DOT com Subject: Re: setup current problems References: <009401c178b4$0d3d92b0$0200a8c0 AT lifelesswks> <3C05FB2F DOT 2050409 AT ece DOT gatech DOT edu> <01c301c178c6$308dc660$0200a8c0 AT lifelesswks> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert Collins wrote: > It's actually a little harder than that. You need to either > a) limit the depth of recursion/stack growth > b) build a network of visited nodes and only recurse into unvisited > nodes. > > I've implemented a), which has the downside that in corner cases, (in > this case, a chain 6 requires: statements long) packages may not get > grabbed. Mind you, this means that of those 7 packages, the user must > select ONLY the first one, and no other packages can require: any > package further down the chain than the 2nd one. I.e. not much of an > issue :}. > > However b) is the proper solution IMO, but more time is needed to do it > right, so I'm leaving that for another day. Hmmm...it seems like dependency graph traversal is a well-studied problem. Perhaps there's a GPL'ed library out there we can use? (since setup is independent of cygwin1.dll itself, we ARE allowed to use pure GPL, non-Red Hat owned code, right?) But, yah, leave it for later...(a) is good for now. --Chuck