From owner-svn-src-head@FreeBSD.ORG Wed Sep 15 18:47:16 2010 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3FD01065673 for ; Wed, 15 Sep 2010 18:47:16 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6CD8B8FC26 for ; Wed, 15 Sep 2010 18:47:16 +0000 (UTC) Received: (qmail 14986 invoked by uid 399); 15 Sep 2010 18:47:15 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 15 Sep 2010 18:47:15 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C9114B2.9090001@FreeBSD.org> Date: Wed, 15 Sep 2010 11:47:14 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: "M. Warner Losh" References: <201009131530.o8DFU9f5010734@svn.freebsd.org> <4C9020C5.90108@FreeBSD.org> <20100914.202936.19192035460743630.imp@bsdimp.com> In-Reply-To: <20100914.202936.19192035460743630.imp@bsdimp.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r212558 - head/usr.bin X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 18:47:16 -0000 On 9/14/2010 7:29 PM, M. Warner Losh wrote: > In message:<4C9020C5.90108@FreeBSD.org> > Doug Barton writes: > : On 9/13/2010 8:30 AM, Warner Losh wrote: > :> Author: imp > :> Date: Mon Sep 13 15:30:09 2010 > :> New Revision: 212558 > :> URL: http://svn.freebsd.org/changeset/base/212558 > :> > :> Log: > :> Move to using Makefile.arch to include the proper target-specific > :> programs. > :> > :> Modified: > :> head/usr.bin/Makefile > :> > :> Modified: head/usr.bin/Makefile > :> ============================================================================== > :> --- head/usr.bin/Makefile Mon Sep 13 15:19:49 2010 (r212557) > :> +++ head/usr.bin/Makefile Mon Sep 13 15:30:09 2010 (r212558) > :> @@ -11,48 +11,29 @@ > :> > :> SUBDIR= alias \ > :> apply \ > :> - ${_ar} \ > : > :> .if ${MK_TOOLCHAIN} != "no" > :> -_ar= ar > : > :> +SUBDIR+= ar > : > : > : I'm curious about why you're changing the method we use to switch > : optional elements. The change seems gratuitous to me, but I'm willing > : to be persuaded. > > I posted these exact patches many times to arch@ and while people > commented on other aspects of the change, no body ever commented on > this aspect of the change (apart from comments about how to do it > better). That's why I specifically said that there was no objection > from arch@ for these changes. I'm not disputing that. Like many other people my time for FreeBSD is limited, much more so lately, and I was not able to review your patches in depth at the time you posted them. My apologies for the late questions. > Doing things this way makes it easier for different architectures to > subset or augment the directories to build (and it makes it a lot > easier to know what's built on a given architecture). They can be > concentrated into individual Makefiles that are easier to select on. > MIPS and ARM are both moving to having multiple names (powerpc moved a > couple of months ago) and the current arrangement doesn't scale well > in the face of these changes. It is far from gratuitous. I understand that what you've written above was your intent in making the change, what I don't clearly understand is why it's better. But you seem to, and AFAICT the change isn't harmful, so I'll take your word for it. FYI, the reason I asked is that there were already a non-trivial number of small differences in the we handle build options in the various release branches, which makes handling support for things like BIND (which has a lot of knobs) "interesting." However it seems like your new build system is going to add a lot of other differences to what will become 9-release anyway, so I suppose once again I'll just struggle along with it. :) Thanks for taking the time to explain your changes in more depth. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/