From owner-freebsd-toolchain@FreeBSD.ORG Wed May 8 05:10:01 2013 Return-Path: Delivered-To: freebsd-toolchain@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 40A365A0 for ; Wed, 8 May 2013 05:10:01 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 09EDF64F for ; Wed, 8 May 2013 05:10:01 +0000 (UTC) Received: by mail-ia0-f174.google.com with SMTP id j3so227145iae.19 for ; Tue, 07 May 2013 22:10:00 -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=OXknUKNVllS4utD+8w86MevQgXt7z9VVaio/2rKtqMo=; b=n4+A2ja0ZNpBvzIMPk1UDjXyZm7sENcYZO92WyYQ+VSNsAVBRQylug8WRckLOiAiN+ qROl/ncVvBZ3eXY8DwXwIhLKijurvvWGEG/sG0OlUigkTw8bXXl2qzg4n6oRdLLqFqT4 iKDQNRzrej+PqJKrl/h57SOn94EV/zXkSCD3yJqVrwlFmheeiMwtUDJp4IPgG6XQt08y glnjxjDEVDJ76OeCacDs+0XgzY0WG4mjU21x2JJDHn1Rf3XsZcSfhcb8Nasy5jEQ0L9k 4tCmGceMJG4diKJa+QTHn5jtkvdc7ssGghk/a9pZuY/hvFZ3Eh1IC86ERtlzvOBmNLeY UMIw== X-Received: by 10.42.21.206 with SMTP id l14mr1277124icb.31.1367989800587; Tue, 07 May 2013 22:10:00 -0700 (PDT) Received: from [10.0.0.53] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id wn10sm1858194igb.2.2013.05.07.22.09.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 May 2013 22:09:59 -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=windows-1252 From: Warner Losh In-Reply-To: Date: Tue, 7 May 2013 23:09:55 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130507203906.GB40460@lor.one-eyed-alien.net> <2E2C2F74-A25B-4B9F-84C4-0A434B8C7EE6@gmail.com> To: Garrett Cooper X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQm8o5/+EDbNNVT4P2UshyRF6UPamA7wRZafBOfvrVd26iGCXA+m3RZp8vea2K0rQQbksIMC Cc: "Simon J. Gerraty" , freebsd-toolchain@freebsd.org, "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 05:10:01 -0000 On May 7, 2013, at 9:42 PM, Garrett Cooper wrote: > 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: > > > >> 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'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 > >>> sections of the tree; contrib stuff needs to set .PATH = appropriately to > >>> 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 an > >>> 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? > >> > >> 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. > > > > This is another good reason. It would make porting code = to/from NetBSD a LOT easier=85 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 local 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. = [${.CURDIR}] > 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/llvm > 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 = current top of the tree. Please, for the love of god, make sure that we = don't lose the infer from top of tree ability, or I will hurt you. = Often. Through all the minions that owe me minor favors. >=20 > I don't want to break that ever; it's a fantastic feature. If you = could point me to where that magic awesomeness lives (make?), I'll be = more than happy 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 makes 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 get > # 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... I thought ports specifically named things differently to avoid = conflicts. Warner