From owner-freebsd-ports Mon Nov 19 13:40:11 2001 Delivered-To: freebsd-ports@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 9163B37B416 for ; Mon, 19 Nov 2001 13:40:02 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id fAJLe2n92780; Mon, 19 Nov 2001 13:40:02 -0800 (PST) (envelope-from gnats) Date: Mon, 19 Nov 2001 13:40:02 -0800 (PST) Message-Id: <200111192140.fAJLe2n92780@freefall.freebsd.org> To: freebsd-ports@FreeBSD.org Cc: From: "."@babolo.ru Subject: Re: ports/32114: WRKDIRs should be moved to a central location Reply-To: "."@babolo.ru Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR ports/32114; it has been noted by GNATS. From: "."@babolo.ru To: cjclark@alum.mit.edu Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: ports/32114: WRKDIRs should be moved to a central location Date: Tue, 20 Nov 2001 00:37:12 +0300 (MSK) Crist J. Clark writes: > > >Number: 32114 > >Category: ports > >Synopsis: WRKDIRs should be moved to a central location > >Confidential: no > >Severity: non-critical > >Priority: low > >Responsible: freebsd-ports > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: change-request > >Submitter-Id: current-users > >Arrival-Date: Mon Nov 19 13:10:00 PST 2001 > >Closed-Date: > >Last-Modified: > >Originator: Crist J. Clark > >Release: FreeBSD 4.4-STABLE i386 > >Organization: > >Environment: > System: FreeBSD blossom.cjclark.org 4.4-STABLE FreeBSD 4.4-STABLE #0: Wed Nov 7 14:50:28 PST 2001 cjc@blossom.cjclark.org:/usr/obj/export/stable/src/sys/BLOSSOM i386 > > > Ports system as of above date. > > >Description: > Presently, the ports Makefiles will by default put the WRKDIR > in ${.CURDIR}/work. For a typical installation this means that a build > in /usr/ports// will put the work files in, > > /usr/ports///work > > At first glance, this seems to make perfect sense. However, > this design has drawbacks. If one wants to make sure there are no > stale work directories around, he can either, > > # cd /usr/ports && make -DNOCLEANDEPENDS > > Which takes a _long_ time, or > > # find /usr/ports -type d -name work -exec rm -rf {} \; > > Which is somewhat faster, but a bit dangerous. > > I would claim that it is better to put all WRKDIRs in a > central location. For example, /usr/ports/work. This has the advantage > that when one wishes to clean out old work directories, a single, > > # rm -rf /usr/ports/work/* > > Will do the trick. This also brings work directories into line with > how distfiles are stored. After all, distfiles are all by default > placed in /usr/ports/distfiles, they aren't kept in > ${.CURDIR}/distfiles even though that would work fine. The only > drawback I can see is that it might be marginally harder for the > novice ports user to find the work directory. However, anyone who > plans to go hacking into the build directory should probably have the > skills to find it. The vast majority of ports users will never know > the difference. > > >How-To-Repeat: > N/A > > >Fix: > For anyone wishing to do this for themselves, a simple, > > WRKDIRPREFIX?= /usr/ports/work > > In /etc/make.conf will do it. However, the reason for the PR is that I > believe somemthing like this would be a better default than the current > design. Just inserting the line above into Mk/bsd.ports.mk would do > it. There are also fancier ways to go so that the build takes place > in, > > /usr/ports/work// Why /usr/.... ? What about WRKDIRPREFIX=${TMPDIR} if TMPDIR defined and no change if not? It is a bad idea to enlage number of filesystems with temporary data. > But they may break existing localizations whereas changing the default > WRKDIRPREFIX from null to something else should not cause any > back-portablility issues. -- @BABOLO http://links.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message