From owner-freebsd-arch@FreeBSD.ORG Wed May 8 05:39:25 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6A559909; Wed, 8 May 2013 05:39:25 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) by mx1.freebsd.org (Postfix) with ESMTP id 37BD0767; Wed, 8 May 2013 05:39:24 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id u10so978651pdi.19 for ; Tue, 07 May 2013 22:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=q2C7KXQ3T0dp2XgrMIGs8XhntdW+quIsMai3Veu8RlY=; b=jsmnUpB0pWfY5zFAWsNlkmmoeFLxYV/KJx6Q55O4dD7FH47CbjbhN2g+lX1vfdmv7e yOFW/x4nOoVcefWJuC0nKbhz9mQg1jrp0X1CEVH2mdBJZiq+woedS3ziu1vIw2p5TRZP PvH4vnAxHZlTrXw2PpmG20LsMHxE1400ia/9R7xTWExTsMfugErcbSC7CkUhABgB2vYA PPXAUDNrAD6Qz+4BkQb+6fBzM786z1qedwtzGZjn0TIogfHuHr1LuPmzKrFsxdl5sBLM gXo9JUnmpjTFlbTAnVSAlj3+ElzcLYQuSHOhfgSyqwwP3tWC/DarTBT/bg8xtfJgV5ZI Z8Nw== X-Received: by 10.66.154.167 with SMTP id vp7mr6428824pab.7.1367991564549; Tue, 07 May 2013 22:39:24 -0700 (PDT) Received: from [192.168.0.139] (174-24-222-208.tukw.qwest.net. [174.24.222.208]) by mx.google.com with ESMTPSA id aj2sm31191034pbc.1.2013.05.07.22.39.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 May 2013 22:39:23 -0700 (PDT) References: <20130507203906.GB40460@lor.one-eyed-alien.net> <2E2C2F74-A25B-4B9F-84C4-0A434B8C7EE6@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=cp932 Content-Transfer-Encoding: quoted-printable Message-Id: <6700AD11-D97D-42D0-9355-0D928CF0E103@gmail.com> X-Mailer: iPhone Mail (10B329) From: Garrett Cooper Subject: Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree Date: Tue, 7 May 2013 22:39:22 -0700 To: Warner Losh Cc: "Simon J. Gerraty" , "freebsd-toolchain@freebsd.org" , Brooks Davis , "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 05:39:25 -0000 On May 7, 2013, at 10:09 PM, Warner Losh wrote: >=20 > On May 7, 2013, at 9:42 PM, Garrett Cooper wrote: >=20 >> On Tue, May 7, 2013 at 2:26 PM, Garrett Cooper wrote= : >>=20 >> On Tue, May 7, 2013 at 2:00 PM, Warner Losh wrote: >>=20 >> On May 7, 2013, at 2:46 PM, Garrett Cooper wrote: >>=20 >>> On May 7, 2013, at 1:39 PM, Brooks Davis wrote: >>>=20 >>>> On Tue, May 07, 2013 at 01:05:07PM -0700, Garrett Cooper wrote: >>>>> Hi, >>>>> A common pattern that I've seen at Isilon and something else that I'v= e >>>>> wanted to have for a while is the ability to designate where the top o= f a >>>>> source tree was. This is important and helpful when dealing with sourc= e >>>>> files that build upon each other or depend on sources located in other= >>>>> sections of the tree; contrib stuff needs to set .PATH appropriately t= o >>>>> point to sources at the top of the tree, sys stuff is riddled with S=3D= in >>>>> order to point to where /sys, etc lives, we build upon FreeBSD within a= n >>>>> expected directory structure as well. >>>>> I haven't come up with a name, but was wondering if this was a good >>>>> idea, and if so does anyone have any outstanding patches for this that= can >>>>> be pushed into FreeBSD? >>>>=20 >>>> I'd like to see this. There's a variable for this in NetBSD and I've >>>> wanted to do this because it makes code easier to relocate within the >>>> tree. >>>=20 >>> This is another good reason. It would make porting code to/from Net= BSD a LOT easier=81c especially because I plan on pulling a lot of test/test= infrastructure code from NetBSD and I really don't want to commit too many l= ocal changes to the Makefiles. Less divergence -> better cross-pollination -= > less work for all -> win for the BSDs. >>> Thanks for the reminder.. I'll base it off what NetBSD did :). >>=20 >> SRCDIR >>=20 >> EVARINUSE? >>=20 >> share/mk/bsd.doc.mk:# SRCDIR Directory where source files live. [${.C= URDIR}] >> share/mk/bsd.doc.mk:TRFLAGS+=3D -I${SRCDIR} >> share/mk/bsd.doc.mk:.PATH: ${.CURDIR} ${SRCDIR} >> share/mk/bsd.doc.mk: cd ${SRCDIR}; \ >> share/mk/bsd.doc.mk:SRCDIR?=3D ${.CURDIR} >> share/mk/bsd.doc.mk: cd ${SRCDIR}; ${UNROFF} ${MACROS} ${UNROFFFLAGS} \= >> share/mk/bsd.doc.mk: cd ${SRCDIR}; ${UNROFF} -ms ${UNROFFFLAGS} \ >> share/mk/bsd.info.mk:SRCDIR?=3D ${.CURDIR} >> ... >> share/doc/llvm/Makefile:SRCDIR=3D ${.CURDIR}/../../../contrib/llv= m >> share/doc/llvm/Makefile:.PATH: ${SRCDIR} ${SRCDIR}/lib/Support >> share/doc/llvm/clang/Makefile:SRCDIR=3D ${.CURDIR}/../../../../= contrib/llvm/tools/clang >> share/doc/llvm/clang/Makefile:.PATH: ${SRCDIR} >>=20 >> Once upon a time, this *HAD* to be set, and wasn't inferred from the curr= ent top of the tree. Please, for the love of god, make sure that we don't lo= se the infer from top of tree ability, or I will hurt you. Often. Through al= l the minions that owe me minor favors. >>=20 >> I don't want to break that ever; it's a fantastic feature. If you could p= oint me to where that magic awesomeness lives (make?), I'll be more than hap= py to address it in my branch where I'm going to do this. >>=20 >> I really don't like how NetBSD turned their top-level build command into a= shell script [in part because it needs to bootstrap a bunch of tools]. It m= akes things painful when doing iterative builds.. >>=20 >> So all in all, I completely and wholeheartedly agree with your concerns. >>=20 >> Oh sweet.. this is something to keep in mind too (from bsd.port.mk)... >>=20 >> # SRC_BASE - The root of the src tree. (Some ports require this to g= et >> # kernel sources). Default: /usr/src >>=20 >> All else fails, ports has done it first -_-... >>=20 >> Not the first var I've seen this done with... >=20 > I thought ports specifically named things differently to avoid conflicts. Perhaps. It matches autoconf too. It's just a pain when there isn't consiste= ncy, but oh well... Thanks! -Garrett=