From owner-freebsd-testing@FreeBSD.ORG Thu Jan 23 22:15:06 2014 Return-Path: Delivered-To: freebsd-testing@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1534DD2; Thu, 23 Jan 2014 22:15:05 +0000 (UTC) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A4F61124B; Thu, 23 Jan 2014 22:15:05 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id rd3so2440177pab.33 for ; Thu, 23 Jan 2014 14:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CVqIDjuTKM1nbnS7pA/OpxjTchBu9vKoeWdzXS8ya3w=; b=M0UO2LeVLS7NhdeiXddzJ+OxOYNrTDuNKJY/r1QBBNWKxNW3KYVOOY7Nocp4och0MO LdnEAF7l4N6TEBQgKMM6UjHNC9w0OeWSg/KC1yIMBaVCExy5k1X4P9C0ufwI/v6J2pC9 3iXF3lj801JAuPUJOzv4Jp+T1xjG6nHwgnrOH2CpBwcpNBZmXhf6QSF9WQ9wvev4yG2N +I4r28p5NkH42kADVTdXpkQ/pS3kRnlfPOLsWDPV1lQurEGYVjc67yryai3Ey7yftq67 Fw/wVgumlviXM8RUh2XFBRUFY47CmGyrAg+9/n2mnA22+tatDR6VoArIl5IAXg+Id2ig ooqA== X-Received: by 10.68.35.129 with SMTP id h1mr10492260pbj.163.1390515305265; Thu, 23 Jan 2014 14:15:05 -0800 (PST) Received: from fuji.zcorp.zonarsystems.com ([64.14.143.130]) by mx.google.com with ESMTPSA id iq10sm41594695pbc.14.2014.01.23.14.15.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Jan 2014 14:15:04 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Makefile.inc1.patch From: Garrett Cooper In-Reply-To: <20140123221142.814FC5807E@chaos.jnpr.net> Date: Thu, 23 Jan 2014 14:15:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7CB7D14F-7848-46B7-AB85-7E16145268D9@gmail.com> References: <4A3E3984-73D3-4441-97A7-D58679EFF978@gmail.com> <9775878D-91AB-4BE4-ADFA-32D8DB582AA6@gmail.com> <20140123210308.0E1D65807E@chaos.jnpr.net> <20140123215430.4B7B15807E@chaos.jnpr.net> <8D80A156-F649-4CA1-846A-DBAE9CC30627@gmail.com> <20140123221142.814FC5807E@chaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.1827) Cc: "freebsd-testing@freebsd.org" , brooks@freebsd.org X-BeenThere: freebsd-testing@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Testing on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 22:15:06 -0000 On Jan 23, 2014, at 2:11 PM, Simon J. Gerraty wrote: >>> For options.mk I allow MK_* to already be set and WITHOUT_* to take >>> precedence over WITH_*. I also allow makefiles to have their own =3D >> lists >>> of options - separate the policy from the mechanism. >>=20 >> Would that fix this case though? >=20 > I imagine it would make fixing it easier. >=20 >>> I guess you could even allow a per-knob setting as to which takes >>> precedence.=3D20 >>=20 >> You mean override the default so WITH_* overrides WITHOUT_*? >=20 > Yes - I expect that would be rare, but worth it for completness. > The important thing is a simple precidence rule. >=20 >>> By simply allowing WITHOUT_* to overrule WITH_*, the Makefile.inc1 =3D= >> usage >>> would be greatly simplified. >>=20 >> Maybe=3D85 the -DNO_* logic is a bit messy=3D85 >=20 > NO_* always wins, it allows a makefile to say "I don't care what you > want I cannot do that". >=20 > Most places you see -DNO_* used could be -DWITHOUT_* if the semantics > were not broken as previously described. > NO_* should be mainly for makefiles to set - like NO_MAN=3D (i don't = got > no man page man) >=20 >> Curious to see what you have in mind :).. >=20 > Look at contrib/bmake/Makefile Ok, I=92ll definitely look at that. Alan, As far as fixing your issue is concerned though, has a fix already been = committed or does one still need to be committed? If the latter, does = this suffice for today =97 with the intent that it will get ripped out = in favor of something cleaner in the [near] future? Thanks! -Garrett=