From owner-freebsd-current Wed Jun 19 12:32:47 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA11240 for current-outgoing; Wed, 19 Jun 1996 12:32:47 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA11235 for ; Wed, 19 Jun 1996 12:32:45 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id MAA25392; Wed, 19 Jun 1996 12:23:56 -0700 (PDT) To: Nate Williams cc: Mark Murray , current@FreeBSD.org Subject: Re: tcl -- what's going on here. In-reply-to: Your message of "Wed, 19 Jun 1996 12:43:27 MDT." <199606191843.MAA06814@rocky.sri.MT.net> Date: Wed, 19 Jun 1996 12:23:56 -0700 Message-ID: <25390.835212236@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Because all of the 'Berkeley' targets don't work. > > 'make depend all install clean cleandir obj' etc.. are *useful* (nay > critical) for some installations. Another strawman argument, I'm afraid. Through encapsulation it would easily be possible to make ALL of these work, and with minimal perturberation to the package. You want NOPROFILE to be passed through when that's applicable? Fine. You want obj, clean and cleandir to work? Fine. I already did that for bsd.port.mk, in fact. You want your debugging flags passed in? No problem. I looked at providing *all* of these for the TCL port and, while I only implemented the ones I thought were critical (obj and cleandir), the rest were pretty trivial. For most, if not all, of the GNU ports I've looked at analogs exist for pretty much all of our standard bmake operations. As I said in my last mail, the obj link wart is our biggest hurdle and I'd just as soon see it die anyway (and that is NOT a new position on my part - I've been complaining about the stupid things for 2 years now). I'm also all for backing this out and getting on with our lives, but I just thought I'd defend what I thought was a little unfair criticism of the proposed mechanism's shortcomings. Whatever else its shortcomings, you can do a LOT of "homogenization" through the ports-style Makefile wrapper. Jordan