From owner-freebsd-arch@FreeBSD.ORG Wed May 8 21:49:23 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 BEC82D4A for ; Wed, 8 May 2013 21:49:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by mx1.freebsd.org (Postfix) with ESMTP id 7DC23F1A for ; Wed, 8 May 2013 21:49:23 +0000 (UTC) Received: by mail-vc0-f171.google.com with SMTP id m16so2159683vca.2 for ; Wed, 08 May 2013 14:49:16 -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=YCU817UR/UuUTScGScD/DjFfy08hdlHgttd/1y9LJgk=; b=bM2uZNB3Nv7PWW4PQUpwzo2aotapALgiwK3XUKqW5u8aPW9pKb2V+ILf8hTWQ7xzWO kLW+DD/8RbU810DQISxjkcdwYc/y7Xt918BEwR/782wqMLfxycwk6pv69MgBZWf/AOpw D+Aq63YkWHC5H96LOdFXgGBHp7/49cKOseB9u3EkST5FFOhRFQJwahX15byNEHtSzIsi HQs6f6vQBopok6hj3aRZNECEcuDdzgnk4G9TPS7tJkJ9eR/Pz2JZaMMNYKjj9GmfCONC GTzPI695BsbL9MqWW4xx0Qa+0XMlyhY/4g1NR4zrNpxA5wz2GNqxkepHJcAb5y08M1WK Qdmg== X-Received: by 10.220.103.138 with SMTP id k10mr5578432vco.74.1368049756770; Wed, 08 May 2013 14:49:16 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id xe6sm613137vec.6.2013.05.08.14.49.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 May 2013 14:49:15 -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: <20130508054121.DCA7258097@chaos.jnpr.net> Date: Wed, 8 May 2013 15:49:12 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9CD1CE3E-C17C-4C63-BA03-190531185D7A@bsdimp.com> References: <20130507213118.5277F58097@chaos.jnpr.net> <20130508054121.DCA7258097@chaos.jnpr.net> To: Simon J. Gerraty X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkJfXr1BAjq7UNlTB5Iz4uoh7USTw5X1HmdxO6l6ASVzrDHhLU6/ACRtZzL9JnRpG2Z5Quo 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 21:49:23 -0000 On May 7, 2013, at 11:41 PM, Simon J. Gerraty wrote: >=20 > On Tue, 7 May 2013 21:25:37 -0600, Warner Losh writes: >> where does MAKEOBJDIRPREFIX come into play? >=20 > I don't normally use it, it is a handy but rather crude implement. > I normally use=20 >=20 > MAKEOBJDIR=3D'${.CURDIR:S,${SRCTOP},${OBJTOP},}' >=20 > which gives you a similar - but much neater result than > MAKEOBJDIRPREFIX. Isn't that backwards. MAKEOBJDIRPREFIX in today's FreeBSD is much more = like OBJTOP than what you've quoted here. That's how I set the top of = the tree today, usually with a 'setenv MAKEOBJDIRPREFIX $HOME/obj' in my = .cshrc so it is always active. That way I can just buildworld or = buildkernel without having to worry where things will wind up, or having = problems with /usr/obj being unwritable... I know this trick doesn't = work for netbsd's make (or didn't years ago when I was building it on a = regular basis), so I assume it is FreeBSD make centric. >> We do it both ways: on some architectures we have multiple =3D >> MACHINE_ARCHes per MACHINE (like mips and arm) and on others we have = one =3D >> MACHINE_ARCH and mutliple machines (like i386 and pc98). >=20 > Yes, which is why I'm adjusting accordingly. >=20 >> We currently use ${MACHINE}.${MACHINE_ARCH} for cross builds, which =3D= >> works out nicely. For historical reasons that turn out to be =3D >> inconvenient, we don't do this for native builds. >=20 >> Why is this gratuitously different than the current scheme?=20 >=20 > Do you mean why not simply use ${MACHINE}.${MACHINE_ARCH} always? > Encoding both MACHINE and MACHINE_ARCH always is doable, but I avoid = '.' > because it prevents being able to use modifiers like :R and :E > to separate the directory component from the target machine spec. The project currently uses dots without issue. Not quite sure why you'd = need to generate things that way. Sure it sounds useful, but it seems = rather a backwards way to work out MACHINE and MACHINE_ARCH (or I'm = misunderstanding what you are saying). > The projects/bmake branch is about showing how freebsd can be built in > meta mode. The tree dependencies are represented as dir.target_spec >=20 >> would I build a pc98 build with this? And why have it be different = for =3D >=20 > it would just get pc98 since there's no ambiguity. > But as noted above, if you wanted to always be explicit that wouldn't = be > a problem (assuming '.' is avoided). >=20