From owner-freebsd-current Wed Sep 8 21:37:21 1999 Delivered-To: freebsd-current@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 65D4115103 for ; Wed, 8 Sep 1999 21:37:16 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from localhost (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id VAA07129; Wed, 8 Sep 1999 21:37:16 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: "John W. DeBoskey" Cc: freebsd-current@FreeBSD.ORG Subject: Re: optional 'make release' speed-up patch In-reply-to: Your message of "Thu, 09 Sep 1999 00:04:39 EDT." <199909090404.AAA71015@bb01f39.unx.sas.com> Date: Wed, 08 Sep 1999 21:37:16 -0700 Message-ID: <7125.936851836@localhost> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The following patch to /usr/src/release/Makefile allows the > specification of the variable FASTCLEAN, which instead of doing > a recursive rm on CHROOTDIR, simply umounts/newfs/mounts. Of > course, this is only useful if your CHROOTDIR location is a > separate mount point (which mine is: /snap). No offense, but this is really pretty ugly for something that I'd anticipate to be a *major* edge case. I've been building releases for years, for example, and I've yet to build one on a filesystem all by itself. I usually just cast around for some space on an existing (shared) fs and go to it, and I suspect that many others are the same way. :-) I'm not saying there shouldn't be a *hook* of some sort for doing "fast cleans", but the patches as they stand add way too much of a delta for only one very specific optimization. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message