From owner-freebsd-testing@FreeBSD.ORG Thu Jan 23 21:30:15 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 09F38ED7; Thu, 23 Jan 2014 21:30:15 +0000 (UTC) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C45C41DBE; Thu, 23 Jan 2014 21:30:14 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id ld10so2373889pab.24 for ; Thu, 23 Jan 2014 13:30:14 -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=6OnRr9kII+QFN1pbQfh4WNnnm33Ez6ZpmsSVH8be9LI=; b=vK2w+Fbb3KUasJKG9YEsHaEoMLXWLU/0MoSS6D7F/Pwwb1ih1mjOIVZcW90h+1krIL us4odzopxFTYwleg7GpUJGRLR4Quyhoa11rtW+SQCBzYlV4XFpypeBTs8spBfhqfmMRw PiTMbSK1DXgj0WRYoqq8/I/9aPR0k4IY/XHrgU1Oe2/sujM+EjTy/FpPSp+3gwUay5L7 3F7NC1hr35ZQtwLxYSg2GpmYshyCEiHOkwMQq0Y4krANvuuKcTeqDSOlzm9ypcGWXgXi 6bRn5ObKNo6nLhCJX2ksR+7M3jHHkEDaEd/uYdBpo3pDv1bptk4mQxYo0wtT9hTljrMU 3YKA== X-Received: by 10.68.96.99 with SMTP id dr3mr10482701pbb.40.1390512614468; Thu, 23 Jan 2014 13:30:14 -0800 (PST) Received: from fuji.zcorp.zonarsystems.com ([64.14.143.130]) by mx.google.com with ESMTPSA id de1sm41229869pbc.7.2014.01.23.13.30.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Jan 2014 13:30:13 -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: <20140123210308.0E1D65807E@chaos.jnpr.net> Date: Thu, 23 Jan 2014 13:30:12 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A3E3984-73D3-4441-97A7-D58679EFF978@gmail.com> <9775878D-91AB-4BE4-ADFA-32D8DB582AA6@gmail.com> <20140123210308.0E1D65807E@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 21:30:15 -0000 On Jan 23, 2014, at 1:03 PM, Simon J. Gerraty wrote: > [+brooks] >=20 > On Thu, 23 Jan 2014 12:53:31 -0800, Garrett Cooper writes: >> Here=3D92s the working patch. The difference between this one = and =3D >> the prior version is that you have to explicitly override -DNO_TESTS = =3D >> when building lib/atf* (Simon: do you have any comments?): >=20 > Not crazy about frobbing ${MAKE} Neither am I, but .export is a bmake only feature. I=92m still using = fmake :(. >> -.if ${MK_TESTS} !=3D3D "no" >> +.if defined(WITH_ATF) || ${MK_TESTS} !=3D3D "no" >> +# Make sure WITH_ATF overrules -DNO_TESTS >> +.if !defined(WITH_ATF) >> +MAKE+=3D3D -DWITH_ATF >> +.endif >=20 > Would it make sense to have ATF or TESTS depend on the other? This functionality was removed several months ago.. otherwise I would = totally agree :/. > As is that can't be done, since one cannot always safely include > bsd.own.mk from the tree. >=20 > I'd really like to see the WITH[OUT]_ processing separated to its own > makefile (I use options.mk) so that it can always be safely used - = even > with an option list specific to a given makefile. Yeah, I would too [in an ideal world], but a lot of stuff is dependent = per-TARGET/TARGET_ARCH and compiler, so things get super complicated = really quickly in that regard. >=20 > The semantics in bsd.own.mk are quite broken and result in a lot of = complex > dancing to keep things working. In this case though, this is complex dancing due to how the different = stages stack upon one another in the build process and the fact that = meta make isn=92t here (yet), so things have to be built in the right = order. This method is one that I=92ve been using for quite some time = without any side effects on multiple machines... >>=20 >> I unrolled most of the local changes to Makefile.inc1 on my =3D >> github fork so it=3D92ll be easier to spot if you diff it against my = tree. Thanks, -Garrett=