Date: Thu, 30 May 1996 09:06:55 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: asami@cs.berkeley.edu (Satoshi Asami) Cc: ports@freebsd.org Subject: Re: Request for feedback: REQUIRES_OS_VERSION feature. Message-ID: <20695.833472415@time.cdrom.com> In-Reply-To: Your message of "Thu, 30 May 1996 02:41:15 PDT." <199605300941.CAA02402@silvia.HIP.Berkeley.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
> First, disabling reinstall based on NO_INSTALL is not necessary, as > reinstall calls install and that will be disabled by NO_INSTALL. I know, I just did that for orthogonality with the package and repackage rules - think of it as an optimization. :-) > Next, check sitting between configure and build is simuly bogus, if > it's not suitable for the user's system, it shouldn't attempt to do > anything. Having a missing dependency (configure -> check) and > calling configure from check is a pretty gross hack too. I know, this was all of 10 minutes work here and I took the path of least resistance (this was the implementation of an _idea_, not so much the final implementation of whatever we adopt - that's why I posted it here rather than simply commit it). If you can come up with a better way of causing ports who's checks fail to skip absolutely everything, that'll be fine by me. While you're in there, why not add an option to make clean's "chain" to dependent ports? It's always annoyed me that you can do a build in port A and have it build ports B, C and D as part of the dependencies but when you then do a make clean from A you still wind up with B, C & D fully populated. Basically, the clean target is next to useless unless you always run it from the top right now. > What we should probably do is to add it to the beginning before > fetch, so it can also be used for other things (security/ssh's > USA_RESIDENT check comes to mind). Let me look into this. Find with me! Just so long as it's not a fatal error to fail the check. Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20695.833472415>