From owner-freebsd-testing@FreeBSD.ORG Fri Jan 24 17:39:38 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 CA69FEA9; Fri, 24 Jan 2014 17:39:38 +0000 (UTC) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7908E1743; Fri, 24 Jan 2014 17:39:38 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id lx4so3209157iec.27 for ; Fri, 24 Jan 2014 09:39:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=RHOA2PRmJjD6BNk/IYVZXKA3jSBgytcD1QhFjM+RWmg=; b=TmCR1ccuy8JbsMQErAKD3KVft0+X55qIYuZuQmwulgSYikbP/IQ2M15YVikmQ9acsh EVdhkQZiftUKYj7UmxOhWtwYnJBHcReR0sP5CInQUIBL76t727hYQY6hm8SobgRXclDK o/nW/5euHldhH1MmwLUFeqpmv5WIdeZq0siZj6GV7HyQmJQz2y8RRB+jJqOPEKNO0pPD GiRrXoTF2NQupMtOV2vPL2sDsXqyntCCkYijSengIRasKxQxgm+Tm2ElF3unz2I0PFHZ aoY3AkL3lxvsuD/CYC/gubzYuxMnWH3XYrc3iRsjB/LOG5oyjuKNm7beb5fxXW464uzo aw6w== X-Received: by 10.50.25.129 with SMTP id c1mr5700274igg.23.1390585177818; Fri, 24 Jan 2014 09:39:37 -0800 (PST) Received: from [10.0.2.128] ([64.14.143.130]) by mx.google.com with ESMTPSA id ac3sm12040741igd.4.2014.01.24.09.39.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Jan 2014 09:39:36 -0800 (PST) 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> <7CB7D14F-7848-46B7-AB85-7E16145268D9@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=cp932 Content-Transfer-Encoding: quoted-printable Message-Id: <31B88FF3-A392-4467-9D95-1414B9583B79@gmail.com> X-Mailer: iPhone Mail (11B554a) From: Garrett Cooper Subject: Re: Makefile.inc1.patch Date: Fri, 24 Jan 2014 09:39:35 -0800 To: Alan Somers Cc: "freebsd-testing@freebsd.org" , Brooks Davis , "Simon J. Gerraty" 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: Fri, 24 Jan 2014 17:39:39 -0000 > On Jan 24, 2014, at 8:58, Alan Somers wrote: >=20 >> On Thu, Jan 23, 2014 at 3:21 PM, Alan Somers wrote:= >>> On Thu, Jan 23, 2014 at 3:15 PM, Garrett Cooper w= rote: >>> On Jan 23, 2014, at 2:11 PM, Simon J. Gerraty wrote: >>>=20 >>>>>> 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 go= t >>>> no man page man) >>>>=20 >>>>> Curious to see what you have in mind :).. >>>>=20 >>>> Look at contrib/bmake/Makefile >>>=20 >>> Ok, I=81fll definitely look at that. >>>=20 >>> Alan, >>>=20 >>> As far as fixing your issue is concerned though, has a fix already been c= ommitted or does one still need to be committed? If the latter, does this su= ffice for today =81\ with the intent that it will get ripped out in favor of= something cleaner in the [near] future? >>=20 >> Umm, I accidentally committed my earlier patch along with a different >> change today. Oops. I'm currently testing your latest patch. I'm >> happy with committing it if it works. >>=20 >> -Alan >=20 > Works for me. Do you want me to commit it for you? Please! The only thing I might do is add a comment stating that WITH_ATF is there ju= st to ensure that lib/atf is built in make libraries, so any code which need= s to link against it later on when -DNO_TESTS, can. Thanks! -Garrett=