From owner-freebsd-arch@FreeBSD.ORG Wed May 8 03:25:48 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DD6CDC3A for ; Wed, 8 May 2013 03:25:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by mx1.freebsd.org (Postfix) with ESMTP id B81B8149 for ; Wed, 8 May 2013 03:25:47 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id lj1so996481pab.4 for ; Tue, 07 May 2013 20:25:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=8l1Y6gXpDuldXt0SA8mQTDGl6WOG1V/aapviw8igWUs=; b=LSGIHsLfHPziKS93aCPrMYfRITHirNT9sm93Lu2jQVH4N2UiHhaFMDzGoWsOXfSSYO isdNrt2pYDzBZS/6tkv0DY36R0/PMewUtiO+u7Q28LAbv5oM7eDahJSuCVZ4UhgBoraz Ksc9ljbW6iLG8SzzbSfrRjBckmGBsssG7FMTpc5xkjBmeVREDg0uq0gcDAb4iUwziyqW X7GQw8F1zipZn2eEJ6f/b2xOEVd+FIEnmYGwX8oZnk5Ce74J5GScUg6KolL26wF1clUU xzrrjaDs2JULzFufJpiZ0PGHFTlaKr9LMxG+zO39qrFQ69v3ryQ1YlTksv8+AbNuwNIV JF6w== X-Received: by 10.66.160.162 with SMTP id xl2mr5780001pab.215.1367983541499; Tue, 07 May 2013 20:25:41 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ya4sm30679591pbb.24.2013.05.07.20.25.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 May 2013 20:25:40 -0700 (PDT) Sender: Warner Losh Subject: Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130507213118.5277F58097@chaos.jnpr.net> Date: Tue, 7 May 2013 21:25:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130507213118.5277F58097@chaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkzp1cy1dqQBnLY38HWXAZXsMe8/DidOQzUESv9+eyoVvHJzk9Q3ii3OU6djLYJG1WrY7m7 Cc: Garrett Cooper , freebsd-toolchain@freebsd.org, "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 03:25:48 -0000 On May 7, 2013, at 3:31 PM, Simon J. Gerraty wrote: >=20 > On Tue, 7 May 2013 13:05:07 -0700, Garrett Cooper writes: >> A common pattern that I've seen at Isilon and something else that = I've >> wanted to have for a while is the ability to designate where the top = of a >> source tree was. This is important and helpful when dealing with = source >> files that build upon each other or depend on sources located in = other >=20 > FWIW I've done this in the projects/bmake branch. >=20 > SRCTOP is the top of the src tree > OBJTOP is the top of the corresponding obj tree > OBJROOT is a common prefix (allows one to deduce where objects for a > different value of $MACHINE will be). where does MAKEOBJDIRPREFIX come into play? > $ make -V '${SRCTOP OBJROOT OBJTOP .CURDIR = .OBJDIR:L:@v@$v=3D${$v}@:ts\n}' > SRCTOP=3D/b/sjg/work/FreeBSD/projects-bmake/src > OBJROOT=3D/var/obj/projects-bmake/ > OBJTOP=3D/var/obj/projects-bmake/amd64 > .CURDIR=3D/b/sjg/work/FreeBSD/projects-bmake/src/bin/cat > .OBJDIR=3D/var/obj/projects-bmake/amd64/bin/cat > $ >=20 > SRCTOP is simple to derrive from where sys.mk is found > and the others can be deduced from that >=20 > SRCTOP:=3D ${.PARSEDIR:H:H:tA} > OBJROOT?=3D ${SRCTOP:H}/obj/ > OBJTOP?=3D ${OBJROOT}${MACHINE} >=20 > though since FreeBSD builds more than one MACHINE_ARCH per MACHINE (in > some cases),=20 >=20 > OBJTOP?=3D ${OBJROOT}${MACHINE_ARCH} >=20 > might make sense. We do it both ways: on some architectures we have multiple = MACHINE_ARCHes per MACHINE (like mips and arm) and on others we have one = MACHINE_ARCH and mutliple machines (like i386 and pc98). We currently use ${MACHINE}.${MACHINE_ARCH} for cross builds, which = works out nicely. For historical reasons that turn out to be = inconvenient, we don't do this for native builds. > For Junos we had the opposite - multiple MACHINEs with same > MACHINE_ARCH. >=20 > I'm currently teaking projects-bmake so it can do the equivalent of > universe so if more than one MACHINE_ARCH is possiblem the OBJTOP ends > up being >=20 > OBJTOP=3D ${OBJROOT}${MACHINE}-${MACHINE_ARCH} >=20 > but for cases like i386, amd64 you just get=20 >=20 > OBJTOP=3D ${OBJROOT}${MACHINE} >=20 > as above. Why is this gratuitously different than the current scheme? Also, how = would I build a pc98 build with this? And why have it be different for = different architectures? The differences like these (although maybe not = this one) make things harder to script for things like nanobsd that = reach into the object tree, though the OBJTOP might be enough to solve = that. Warner