From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 1 23:14:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A7EAB1065672; Mon, 1 Oct 2012 23:14:51 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6E9528FC0A; Mon, 1 Oct 2012 23:14:51 +0000 (UTC) Received: by padbi1 with SMTP id bi1so5329518pad.13 for ; Mon, 01 Oct 2012 16:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=CBDb5KN/i0qH0pY1Y4rPEUQWiLer88/3s3eZFuBshHY=; b=buB2kkAXTkStesPl5TJcWyHSnQQn8mEPDLuP6iB61E5WkQyrzmdN0M3QrTrELNiURx y3lysYxRNbRr2YDrz7XEB6bXLGUbGnhhBOqWzpulaXXE/k7s+kSZQ8z7xaNGK3qLBJe2 onUHrrgO3yX/lvItz1G3X/jtrhwxyvgjbQVUndZDMRWNU/7iFZ4QF8u1vgnlO5ZnMTO7 wXWY8AqA9BNWg99NFh3HihlREMVdUH7AW6zx1l/UUJvtnnKnFsIqWiXWY2/k1ooeqdA6 jxF+sfMcW4kE4bZJ8nV/LwFTWGp3rz6jacKCkWqqaVw4WS/iMVwGE/N2HGz4Fwq1bUdd ge4g== Received: by 10.66.88.233 with SMTP id bj9mr39656786pab.72.1349133290901; Mon, 01 Oct 2012 16:14:50 -0700 (PDT) Received: from fuji-wireless.local (c-24-19-191-56.hsd1.wa.comcast.net. [24.19.191.56]) by mx.google.com with ESMTPS id py9sm10951798pbb.20.2012.10.01.16.14.48 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Oct 2012 16:14:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Garrett Cooper In-Reply-To: <20121001223100.E7D0D58093@chaos.jnpr.net> Date: Mon, 1 Oct 2012 16:15:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121001223100.E7D0D58093@chaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.1278) Cc: freebsd-hackers@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 23:14:51 -0000 Hi Simon! On Oct 1, 2012, at 3:31 PM, Simon J. Gerraty wrote: > Hi Garrett, >=20 >>> From: Garrett Cooper >>> Subject: [CFT/RFC]: refactor bsd.prog.mk to understand multiple =3D >> programs instead of a singular program >>> Date: September 2, 2012 11:01:09 PM PDT >>> To: freebsd-hackers@freebsd.org >>> Cc: "freebsd-arch@FreeBSD.org Arch" >>> =3D20 >>> Hello, >>> I've been a bit busy working on porting over ATF from NetBSD, and >=20 > Thanks, we've been using ATF in Junos for a while and glad to see it=20= > being imported to FreeBSD. Thanks (and I appreciate the help marcel@ has given by taking the first = step in importing it). >>> one of the pieces that's currently not available in FreeBSD that's >>> available in NetBSD is the ability to understand and compile = multiple >>> programs. In order to do this I had to refactor bsd.prog.mk (a lot). >=20 > A change like this to bsd.prog.mk can have considerable fallout. > Eg. any makefile that tweaks OBJS is suddenly out of luck. Well=85 any Makefiles attempting to be "clever" (e.g. crunchgen) are out = of luck and would need to change. Most [include] Makefiles will see = virtually no change. > Not to mention the fact that bsd.prog.mk goes from being relatively > simple, to unspeakably hard to read, and all for rather limited = return.=20 I sort of tried to match bsd.prog.mk in NetBSD in the beginning, but = things diverged from there=85 I'm sure things could be made more = readable so any comments would be much appreciated :)! > Apart from ATF, is there any huge demand for building multiple progs = in > the same directory? Well, I noticed that there are a couple ugly messes in the gnu/... = directory that attempt to work around the fact that bsd.prog.mk doesn't = support more than one program by being tricky and emulating bsd.prog.mk = instead of solving the generic problem (and once I got over that = compatibility issue I stopped tracking this class of consumer). Most = consumers don't care (they split up programs into different directories = or use hardlink hacks/basename detection to differentiate one program = functionally from another). Getting back to the idea at hand, the enhancement goal was to get the = testcases to live [and optionally be built/installed] with the source = code to avoid bitrot; I know this isn't the current NetBSD design, but = this is what was requested be done by gnn, marcel, and mdf, and I agree. = It order to do this, I need to be able to build multiple programs so = things are as transparent. On the flipside, bsd.prog[s].mk can live on = its own, be pulled in automatically by bsd.test.mk, and that would be = it. This encourages code duplication though and bugs can persist in = either Makefile, when I'd rather work out all the kinks in whatever = succeeds the legacy bsd.prog.mk file. > FWIW we use progs.mk (as bsd.progs.mk) from > ftp://ftp.netbsd.org/pub/NetBSD/misc/sjg/mk-*.tar.gz=20 > It isn't ideal, but it certainly avoids a lot of churn and complexity > for what is essentially a corner case. This requires pulling bmake into FreeBSD proper in order for things to = function the last I checked as bsd.prog.mk depends upon bmake directives = in order to function properly 100% of the time (and there are external = dependencies and assumptions one has to deal with when using = bsd.prog.mk, etc from NetBSD that made that a bit of a no-go without = refactoring/pulling in bits from NetBSD). I could be wrong though, so = please let me know if I am :). Ideally however, I would like doing this compared to running a custom = build infrastructure, but (as you probably know) this requires = rototilling the current FreeBSD build system to a large degree = (definitely not impossible=85 just needs time and effort). > We have an atf.test.mk which leverages that. > It also handles automatically running the tests if building for the > host. This allows us to fail the build if any unit-tests do not pass. Hmm=85 that wasn't really the end-goal of bsd.test.mk based on my = reading, but I'm sure Julio would be interested in it. I need to do = adjusting in order to allow automatically executing testcases compatible = to the host architecture, but that isn't hard to do (no more than a = couple hours work). > Note, atf.test.mk is loosely derrived from NetBSD's bsd.tests.mk, but > named for what it is (ATF specific tests) since we wanted the > flexibility to have more than one test framework. bsd.test.mk in NetBSD isn't completely test-agnostic, but it isn't = entirely ATF centric either. I'm trying not to stray too far from NetBSD = in this area because there really isn't any reason to do so. FWIW I'd = like to see other test frameworks (lua, unittest//nose, etc) just snap = into bsd.test.mk as easily as possible as it would make some groups = lives easier, but that requires a bit more thought for another day. Thanks for the feedback! -Garrett=