From owner-freebsd-current Mon Oct 12 05:21:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA14439 for freebsd-current-outgoing; Mon, 12 Oct 1998 05:21:55 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA14433; Mon, 12 Oct 1998 05:21:54 -0700 (PDT) (envelope-from rkw@Dataplex.NET) Received: from [208.2.87.5] (user5.dataplex.net [208.2.87.5]) by shrimp.dataplex.net (8.9.1/8.9.1) with ESMTP id JAA07575; Mon, 12 Oct 1998 09:01:59 -0500 (CDT) (envelope-from rkw@dataplex.net) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <199810121159.NAA01144@gratis.grondar.za> References: Your message of " Mon, 12 Oct 1998 06:49:26 EST." (message from Karl Pielorz on Sun, 11 Oct 1998 20:46:53 +0100 (BST)) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 12 Oct 1998 07:20:25 -0500 To: Mark Murray From: Richard Wackerbarth Subject: Re: Never ending 'make clean' in kde port? Cc: asami@FreeBSD.ORG (Satoshi Asami), kpielorz@tdx.co.uk, eivind@yes.no, current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 6:59 AM -0500 10/12/98, Mark Murray wrote: >There already exists a knob; NOCLEANDEPENDS=yes. Perhaps it needs some >refinement? >Write the code, and if folk like it, they'll commit it. Sorry, Mark. Although I think that the default should be reversed such that the clean is not recursive, this does not address the problem. The problem occurs when someone wants to do a recursive clean. The present methodology repeatedly cleans subtrees because they appear multiple times in the full walk of the dependancy tree. The desired behavior would recognize the common subtree and truncate the repeated walks of those subtrees. One method to accomplish this is to allow "make" to establish a target for each of the nodes. Another method would be to have the individual "Makefile"s test to see if there is anything to clean and reccur only if there were. This method would produce slightly different results. Assume that "A" requires "B". Start from a 'clean' tree. Make "B". Now clean "A". In the present methodology, you clean not only "A", but also everything that it requires. Thus "B" would also be cleaned. In the latter methodology, "B" would not be examined because it was not make dirty as a result of building "A". It is unclear which result is "correct". Richard Wackerbarth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message