Date: Fri, 26 Apr 2002 17:28:14 -0700
From: Maxime Henrion <mux@freebsd.org>
To: ports@FreeBSD.org
Cc: Edwin Groothuis <edwin@mavetju.org>
Subject: Re: patch to have make clean not recurse in ${PORTSDIR}
Message-ID: <20020427002814.GE42922@elvis.mu.org>
In-Reply-To: <20020427101938.A77837@k7.mavetju.org>
References: <20020424224454.GM88736@elvis.mu.org> <20020424191430.W62277-100000@zoot.corp.yahoo.com> <20020426204935.GA42922@elvis.mu.org> <3CC9D357.9010105@owt.com> <20020426224107.GB42922@elvis.mu.org> <20020427090419.F56612@k7.mavetju.org> <20020426232017.GC42922@elvis.mu.org> <20020427094000.H56612@k7.mavetju.org> <20020426235247.GD42922@elvis.mu.org> <20020427101938.A77837@k7.mavetju.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Edwin Groothuis wrote: > The expected behaviour of a "make clean" in a port-directory (i.e. > /usr/ports/archivers/unzip) is to clean after the compilation/installation > of that port. Ports have dependencies, so the directories of the > dependency-ports also have to be cleaned (for the just-in-case > scenario where one or more dependencies had to be build also) > > The expected behaviour of a "make clean" in a ports-directory (i.e. > /usr/ports or /usr/ports/archivers) is to clean the directories > below it. A ports-directory can have a port-directory below it, in > which case that one has to be cleaned, or another ports-directory, > in which case it should dive into that and do a "make clean" there > too. I don't actually disagree with this, but I would like NOCLEANDEPENDS=yes to be the default for /usr/ports first, because this case has less impact and annoys a lot of people. The rest can be discussed after. > > Uh ? In what way ? The only case that my patch would broke that I am > > able to imagine is if there was some port in /usr/ports depending on > > another port not itself in this tree but elsewhere, which is *very* > > unlikely. > > It will break if the port itself has a clean-target. Not all of > them, actually probably close to "none of them" has it, but they > have the capability to have one and that is something which should > be reserved. That's right. I think it's a good thing if my patch breaks something which a port shouldn't do anyway, though. :-) Maxime 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?20020427002814.GE42922>