From owner-freebsd-toolchain@FreeBSD.ORG Mon May 6 00:44:41 2013 Return-Path: Delivered-To: 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 72995792 for ; Mon, 6 May 2013 00:44:41 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 59777612 for ; Mon, 6 May 2013 00:44:40 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r460R14O032009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 5 May 2013 17:27:01 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r460R1EU032008 for toolchain@FreeBSD.org; Sun, 5 May 2013 17:27:01 -0700 (PDT) (envelope-from jmg) Date: Sun, 5 May 2013 17:27:01 -0700 From: John-Mark Gurney To: toolchain@FreeBSD.org Subject: patch to add AES & PCLMUL intrinsics to gcc Message-ID: <20130506002701.GK1491@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 05 May 2013 17:27:01 -0700 (PDT) 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: Mon, 06 May 2013 00:44:41 -0000 I'd like to get a review of this patch: https://www.funkthat.com/~jmg/gcc.intrin.patch This adds the AES and PCLMUL intrinsics for gcc... This is the next step in getting a higher performing AES-NI in the kernel while keeping compatibility w/ gcc (and possibly back porting to 9-stable)... One question I have is that I copied wmmintrin.h from clang... It has a license statement, but no copyright statement... Do I need to add one from somewhere? I have verified that these intrinsics get compiled the same way that clang compiles them. Thank you for the review. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-toolchain@FreeBSD.ORG Mon May 6 08:39:45 2013 Return-Path: Delivered-To: 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 3A0FA7D for ; Mon, 6 May 2013 08:39:45 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id EC06DE07 for ; Mon, 6 May 2013 08:39:44 +0000 (UTC) Received: from [192.168.0.2] (cpc10-cmbg15-2-0-cust123.5-4.cable.virginmedia.com [86.30.246.124]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r468dfqM017114 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 6 May 2013 08:39:43 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: patch to add AES & PCLMUL intrinsics to gcc From: David Chisnall In-Reply-To: <20130506002701.GK1491@funkthat.com> Date: Mon, 6 May 2013 09:39:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130506002701.GK1491@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1499) Cc: toolchain@FreeBSD.org 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: Mon, 06 May 2013 08:39:45 -0000 On 6 May 2013, at 01:27, John-Mark Gurney wrote: > One question I have is that I copied wmmintrin.h from clang... It has = a > license statement, but no copyright statement... Do I need to add one > from somewhere? The clang headers are all supposed to have a UIUC license header. If = you find one that is missing, then file a bug report upstream. =20 David From owner-freebsd-toolchain@FreeBSD.ORG Mon May 6 09:12:59 2013 Return-Path: Delivered-To: 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 C023BF76; Mon, 6 May 2013 09:12:59 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 85F186E; Mon, 6 May 2013 09:12:59 +0000 (UTC) Received: from spaceball.andric.com (spaceball.andric.com [IPv6:2001:7b8:3a7:0:204:4bff:fe01:de8a]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 6FB955C5B; Mon, 6 May 2013 11:12:56 +0200 (CEST) Message-ID: <51877413.4020100@FreeBSD.org> Date: Mon, 06 May 2013 11:12:51 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: David Chisnall , John-Mark Gurney Subject: Re: patch to add AES & PCLMUL intrinsics to gcc References: <20130506002701.GK1491@funkthat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: toolchain@FreeBSD.org 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: Mon, 06 May 2013 09:12:59 -0000 On 2013-05-06 10:39, David Chisnall wrote: > On 6 May 2013, at 01:27, John-Mark Gurney wrote: > >> One question I have is that I copied wmmintrin.h from clang... It has a >> license statement, but no copyright statement... Do I need to add one >> from somewhere? > > The clang headers are all supposed to have a UIUC license header. If you find one that is missing, then file a bug report upstream. All of the clang headers have this at the start: /*===---- smmintrin.h - SSE4 intrinsics ------------------------------------=== * * Permission is hereby granted, free of charge, to any person obtaining a copy * of this software and associated documentation files (the "Software"), to deal * in the Software without restriction, including without limitation the rights * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell * copies of the Software, and to permit persons to whom the Software is * furnished to do so, subject to the following conditions: * * The above copyright notice and this permission notice shall be included in * all copies or substantial portions of the Software. * * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN * THE SOFTWARE. * *===-----------------------------------------------------------------------=== */ E.g., there is no copyright statement, and it seems to be a BSD/MIT-like license... From owner-freebsd-toolchain@FreeBSD.ORG Mon May 6 11:06:54 2013 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 96B87A23 for ; Mon, 6 May 2013 11:06:54 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 617E3A19 for ; Mon, 6 May 2013 11:06:54 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r46B6s40023966 for ; Mon, 6 May 2013 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r46B6rox023964 for freebsd-toolchain@FreeBSD.org; Mon, 6 May 2013 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 6 May 2013 11:06:53 GMT Message-Id: <201305061106.r46B6rox023964@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-toolchain@FreeBSD.org Subject: Current problem reports assigned to freebsd-toolchain@FreeBSD.org 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: Mon, 06 May 2013 11:06:54 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/175930 toolchain [headers] clang does not define __STDC_ISO_10646__, de 1 problem total. From owner-freebsd-toolchain@FreeBSD.ORG Tue May 7 06:20:25 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 13D0DB87; Tue, 7 May 2013 06:20:25 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by mx1.freebsd.org (Postfix) with ESMTP id 96CB9172; Tue, 7 May 2013 06:20:24 +0000 (UTC) Received: by mail-vc0-f176.google.com with SMTP id ib11so163772vcb.7 for ; Mon, 06 May 2013 23:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=SYjQP34PLhMNXPrvg1+fI7TcPhQBtxTjq8d+a1Qm9kk=; b=z+HaExWQVig0R1ZYdOqB/H3A2h4uNkuyL6zqSzYgxNznBReJxxTrpzuNy/xVvv4wjS Yr1anhT0wtMFFH2/rjg80wheUqm8R0BiRzPdlI/B/kO+b8jA1OIHD1NtwZEjWqwEEwpe IwpgLHMxgS49Zaq7ijRcFx6si79dRQw+A+jlN1OrJGNObZ4l/MQ3bq5Cf7QAsZWhlCU2 Lc4Wwqr/U4D3xsG2WDdsVJ88HCq2qD78e0lCWaorqx9wLHq5YQyoup5ktvU8IMwM3LAV mHCQa1usJrY5AL3qSnkJr+gP6Hm2KoOtnMpxROhzBBCEqCyh9ar7ERS5XgnxcO0MK+vJ AlMg== MIME-Version: 1.0 X-Received: by 10.52.156.99 with SMTP id wd3mr258829vdb.98.1367907618095; Mon, 06 May 2013 23:20:18 -0700 (PDT) Received: by 10.220.141.72 with HTTP; Mon, 6 May 2013 23:20:18 -0700 (PDT) In-Reply-To: <20130501220750.GD45806@lor.one-eyed-alien.net> References: <201305012123.r41LNcEL048006@red.freebsd.org> <201305012130.r41LU031023258@freefall.freebsd.org> <20130501220750.GD45806@lor.one-eyed-alien.net> Date: Mon, 6 May 2013 23:20:18 -0700 Message-ID: Subject: Re: Fwd: docs/178286: [PATCH] document the LOCAL_* vars in build(7) From: Garrett Cooper To: Brooks Davis Content-Type: text/plain; charset=ISO-8859-1 Cc: sjg@freebsd.org, toolchain@freebsd.org, russell.cattelan@isilon.com, joel@freebsd.org 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: Tue, 07 May 2013 06:20:25 -0000 On Wed, May 1, 2013 at 3:07 PM, Brooks Davis wrote: > > On Wed, May 01, 2013 at 02:35:17PM -0700, Garrett Cooper wrote: >> Hi Brooks and Joel, >> I'd really appreciate if you guys could help out with this. I'm >> having to fix the Isilon build system due to severe lack of >> documentation in build(7). So many mistakes have been made because >> people don't understand how to write FreeBSD Makefiles... > > One minor concern I have with this patch is documenting LOCAL_LIB_DIRS. > I've not posted to the lists yet, but now that I understand buildworld > better, I think I implemented it wrong. It should have required that > the directories be also be listed in LOCAL_DIRS. The reason is that you > could then have LOCAL_DIRS=foo and LOCAL_LIB_DIRS=foo/lib so you only > added one directory to the FreeBSD tree but could still have libs. I > feared that someone might have started using this feature which would > mean we can't easily change that. That's assuming that someone hasn't hacked the base system (e.g. bin/cp, etc) and introduced awesome build dependencies on external libraries that don't cleanly fit into the current structure for buildworld :). This is part of the reason why I opened up http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/178066 , but I realize that this is starting to turn into a slippery slope and could be articulated via meta-make and proper DPADD definitions _much_ better than it is today... Makefile.inc1 is full of pixie dust and carefully placed dependencies today, such that once you step outside that box it's difficult to work within the system due to its lack of flexibility and hooks. It's nice that the __L ".PHONY" rules are automatically generated by Makefile.inc1 because I really want buildworld-ish encapsulation; in particular, the way things are done in the OneFS build system could really be done better -- I'm not confident that some of my predecessors working on the build system truly understood how the FreeBSD build process works or were under extreme time crunches and thus didn't look for a perfect/good solution and instead resorted to some nasty build hacks that I'm now trying to unwind. > Is Isilon using it? Russell and I started using it recently. I'd like this support to stick around until meta-make can be realized (even if it's going to get ripped out eventually...) as it does make things cleaner when people hack away at the base system. Thanks! -Garrett From owner-freebsd-toolchain@FreeBSD.ORG Tue May 7 20:05:09 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 81992D9D; Tue, 7 May 2013 20:05:09 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by mx1.freebsd.org (Postfix) with ESMTP id E4316F1B; Tue, 7 May 2013 20:05:08 +0000 (UTC) Received: by mail-bk0-f44.google.com with SMTP id jk13so506121bkc.17 for ; Tue, 07 May 2013 13:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=QBGzN5fFjOOX55XtoubzVGxSa13CrKBuemTbsXRlK8s=; b=BRD5Gk84VRFJJQOt2b2kw52FJrzK3ZCBagMJKccxfpszihITTsLUiDX02Ho4cjMNhP dqNPFP97/kIdNXcbGVR6tZTjfojHZ2G4g3e56R4UVKffsZ4nSgrr4qw2CPW4SpJ+7+cm DVIVSb4/mMtKeiDFtjUjpwTDPnNnaBL9RWJvIskCw2bkXjdluwUCcIkjaYdzDAovLWko DJMBLCbX9N+znCUNRH5AnOy6Q604PaR2RT7MJWjxlcWp1swMCLT1EhjOLU1cZp1aYHlO mTIQHKvXhP+ZKnLr0M+FAztqFikzzfdzy22gcaGEs+EZZ1Eu9XwHCufOlyGA5Cb0tsOH Fuhg== MIME-Version: 1.0 X-Received: by 10.205.36.138 with SMTP id ta10mr1022195bkb.4.1367957108077; Tue, 07 May 2013 13:05:08 -0700 (PDT) Received: by 10.204.225.206 with HTTP; Tue, 7 May 2013 13:05:07 -0700 (PDT) Date: Tue, 7 May 2013 13:05:07 -0700 Message-ID: Subject: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree From: Garrett Cooper To: freebsd-toolchain@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "Simon J. Gerraty" , "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: Tue, 07 May 2013 20:05:09 -0000 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= 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? Thanks! -Garrett From owner-freebsd-toolchain@FreeBSD.ORG Tue May 7 20:12:21 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6B494F9F; Tue, 7 May 2013 20:12:21 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 500D9F78; Tue, 7 May 2013 20:12:21 +0000 (UTC) Received: from zeta.ixsystems.com (c-67-188-85-47.hsd1.ca.comcast.net [67.188.85.47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 0564611E45; Tue, 7 May 2013 13:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1367957541; bh=qDuVicUWCd11p953GIcNX2kSFkG9NhingWFgQAIj+ps=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=0p/WZWpFjnjy5bVeFJ8fOqGXUNBXEw8ylJbqZAjsKHxHjwTTdTyhxaaq0hKxLAcgf K0wvGFR0XqTsMiveqfAI6/AS7EIEWfHobAlNI11oR10RAesDjzN2kWd4QFgmEQRZNO p51kqC4zhw23iWiPtA9jB26pL9k1QzKHMPC7coeo= Message-ID: <51896021.6010900@delphij.net> Date: Tue, 07 May 2013 13:12:17 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Garrett Cooper Subject: Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-arch@FreeBSD.org Arch" , freebsd-toolchain@freebsd.org, "Simon J. Gerraty" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 20:12:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/07/13 13:05, 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= 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? Is there anything wrong with the current '../../' approach? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJRiWAhAAoJEG80Jeu8UPuzEJcH/2t8EwktBcuka5r2guXD8ft5 ZFFRH/9/12cxU6L17WRgugL8NPfw37c5qszkIXVqW+WK8ojn/o50Oe4qG48cAbdY rUPQJ3jTxpssm7SRHECu+6z/p5wbNV1xW5Vr1KXn2VYJUQ6BGgfg1NzZAibu0Zp7 gcRxiHAyBI+7CaRDrx91XCf+0AdUYnol3BLrHauSRX/m6ZeSh5NIc3z+aFnIG4Jt Qv25ekPBFtXG/zjzY8x8kIYD/lyMxmXSyW2+OoNMbYEH6JQY/D/dvtm41dbDVw2J 0ZfhQETqogpYybrc/4iro99w4gIfoUpYVf4LE65Q3ZhQmaE+suSPr1C5tdc2tF4= =Q5Hr -----END PGP SIGNATURE----- From owner-freebsd-toolchain@FreeBSD.ORG Tue May 7 20:27:25 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8CF7E327; Tue, 7 May 2013 20:27:25 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by mx1.freebsd.org (Postfix) with ESMTP id EC2A8FF0; Tue, 7 May 2013 20:27:24 +0000 (UTC) Received: by mail-bk0-f52.google.com with SMTP id q16so518978bkw.11 for ; Tue, 07 May 2013 13:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=732HaSfgza7QxyvrcoFufnMsPM4m+AZAieBu7XGT3e0=; b=xMpMqrfn77AN/0JVUjnrlaB2MIFU0t1aJpv2P4zI20jxgF5pMXF35QrgyHBs7+IS89 XKJiV0bNdGhYAX8o3mO+0LxRWR7Q8GvF9wJpXOi4K++LBvN2NaXL+BW89PoEPnyB8hMu AyQm0IAYEBrXUF9ItrqSTANcDaFszqpEEKxkxZiEjSz7iz2+kyUre881Xh8RNFKsLTCF WIpxmqOK8hgf5AoFYUiNPwbtpKBvexGODgTlcTnNC7vsnYWB5JQULmcgyTxiXx3kUkMD o/6AzfbVNb4GARHVnq5rbW3y+Lz1F/s2r7gDbysR2vUwaJRYl1lfRL6eG0Q/OFx3f9fc 5Yqg== MIME-Version: 1.0 X-Received: by 10.204.244.198 with SMTP id lr6mr1038392bkb.1.1367958444071; Tue, 07 May 2013 13:27:24 -0700 (PDT) Received: by 10.204.225.206 with HTTP; Tue, 7 May 2013 13:27:24 -0700 (PDT) In-Reply-To: <51896021.6010900@delphij.net> References: <51896021.6010900@delphij.net> Date: Tue, 7 May 2013 13:27:24 -0700 Message-ID: Subject: Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree From: Garrett Cooper To: Xin LI Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arch@FreeBSD.org Arch" , freebsd-toolchain@freebsd.org, "Simon J. Gerraty" 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: Tue, 07 May 2013 20:27:25 -0000 On Tue, May 7, 2013 at 1:12 PM, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 05/07/13 13:05, 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= 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? > > Is there anything wrong with the current '../../' approach? > Not in particular, other than our variable (ISI_TOP) is used in referencing ${.CURDIR} and ${.OBJDIR}, and it's easy to make mistakes if you goof up the dot-dots. With a properly defined directory like that it makes things unambiguous in my mind and with a proper name it makes pathing more intuitive than it currently is. Besides, it would make some other things cleaner, like the dot-dot magic that config(8), etc does. Thanks! -Garrett From owner-freebsd-toolchain@FreeBSD.ORG Tue May 7 20:39:08 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 63F2D729; Tue, 7 May 2013 20:39:08 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id A561EC7; Tue, 7 May 2013 20:39:07 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r47Kd6fd058035; Tue, 7 May 2013 15:39:06 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r47Kd6nM058034; Tue, 7 May 2013 15:39:06 -0500 (CDT) (envelope-from brooks) Date: Tue, 7 May 2013 15:39:06 -0500 From: Brooks Davis To: Garrett Cooper Subject: Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree Message-ID: <20130507203906.GB40460@lor.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rS8CxjVDS/+yyDmU" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-arch@FreeBSD.org Arch" , freebsd-toolchain@freebsd.org, "Simon J. Gerraty" 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: Tue, 07 May 2013 20:39:08 -0000 --rS8CxjVDS/+yyDmU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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= 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. -- Brooks --rS8CxjVDS/+yyDmU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFRiWZpXY6L6fI4GtQRAi8HAJ0fOeFrOZQuxZ7XIDQrZcpufMRVPgCff47g CxnMzuy2Rf0RdQhOTFWH0Tw= =zNT2 -----END PGP SIGNATURE----- --rS8CxjVDS/+yyDmU-- From owner-freebsd-toolchain@FreeBSD.ORG Tue May 7 20:46:40 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 845C6946; Tue, 7 May 2013 20:46:40 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) by mx1.freebsd.org (Postfix) with ESMTP id 54E20128; Tue, 7 May 2013 20:46:40 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id 10so697706pdi.1 for ; Tue, 07 May 2013 13:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=8OUq4e37wdvhYb3hEQxBfGARm7P1YixLzowWlb9ecnI=; b=Zib7s+PC8atxzjjw69geZ8hBD/w8DCoTFgCIK4ZtGSfdXc4L4iCo6YZbRQ7hsBbdte pQDLvSn5VbvP4EhlN2UfASpi19A07Gnyc+ISXCIvI4PIPtteDXNT5JWqv2TLFRbsC6/z bNnbH7AkxEgNIxidLpQfCvNaDaO8nXPZT5RJLAjrdIL+Op9zeBKWIerjmUmaGx/KU7sT Xg2lgOoppOYFySdDzj57s/0KTeuRm/yLH7qR1J3IAql9O2faRnbcENsEoUrT14hINbFW AFI+OZaP1mGcJ/Hrt2kZ1Gex5LXI606aJBEhkytIkk43REtAnw/1hOHwW1MX6D6IMiAc RnEg== X-Received: by 10.66.121.202 with SMTP id lm10mr4679081pab.138.1367959599760; Tue, 07 May 2013 13:46:39 -0700 (PDT) Received: from [192.168.242.58] (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by mx.google.com with ESMTPSA id sa6sm29509099pbb.26.2013.05.07.13.46.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 May 2013 13:46:38 -0700 (PDT) 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 v1283) Content-Type: text/plain; charset=windows-1252 From: Garrett Cooper In-Reply-To: <20130507203906.GB40460@lor.one-eyed-alien.net> Date: Tue, 7 May 2013 13:46:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2E2C2F74-A25B-4B9F-84C4-0A434B8C7EE6@gmail.com> References: <20130507203906.GB40460@lor.one-eyed-alien.net> To: Brooks Davis X-Mailer: Apple Mail (2.1283) Cc: "freebsd-arch@FreeBSD.org Arch" , freebsd-toolchain@freebsd.org, "Simon J. Gerraty" 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: Tue, 07 May 2013 20:46:40 -0000 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? >=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. 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 :). Thanks, -Garrett= From owner-freebsd-toolchain@FreeBSD.ORG Tue May 7 20:58:12 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D6FB9B73; Tue, 7 May 2013 20:58:12 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by mx1.freebsd.org (Postfix) with ESMTP id 8D3D719D; Tue, 7 May 2013 20:58:12 +0000 (UTC) Received: by mail-ve0-f179.google.com with SMTP id oz11so1103514veb.10 for ; Tue, 07 May 2013 13:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=N3fEH2M5pdXsZTyzYTeBsuWs+zKm6Ynzt/AtAGXJ4k0=; b=GMMNe0Kf+X+KNIciGzbEzdC72r9anTNVSTad5x5YIXJIZ4NwyqbSNef9IVuNgtWu3V /YRpEHqZnRMlZ5R7kCgbCYvYGLo4rTQblHTPd8YakkLLKwH+8NmcUTk4z0t9BTPP78NP jqvTTr3toeRaBSyfMYvJhC3yiE0tpcX2NEX/PvejsGDmqJHQFZIf1yhWP9jqsmEA2Ao1 GuMH7NVczBvTJjkgY40mzaNzOd3SqBbZEO2Xbvls5fmn98JlrkNDloIo9hnWZSQcDu2d JIXi2XkYyZlXZFN/ZTx/+WwxR5fB/kHbVg4usS4UAkXxyuhwQCrYjx0XqdfbM0Md6r+O R6pg== MIME-Version: 1.0 X-Received: by 10.52.21.173 with SMTP id w13mr2072722vde.99.1367960292154; Tue, 07 May 2013 13:58:12 -0700 (PDT) Received: by 10.220.141.72 with HTTP; Tue, 7 May 2013 13:58:12 -0700 (PDT) Date: Tue, 7 May 2013 13:58:12 -0700 Message-ID: Subject: clang doesn't make temporary files in all instances, causes build races by not using mk*temp(3) in /tmp From: Garrett Cooper To: dim@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Cc: toolchain@freebsd.org 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: Tue, 07 May 2013 20:58:12 -0000 Hi Dimitriy, I ran into the following error when trying to execute make tinderbox with FreeBSD svn head with ATF changes I'm going to push to benno@: cc -O -pipe -DHAVE_CONFIG_H -I/scratch/freebsd/head-svn/gnu/lib/libgomp -I. -I/scratch/freebsd/head-svn/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/scratch/freebsd/head-svn/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -Qunused-arguments -c /scratch/freebsd/head-svn/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix/bar.c -o bar.o cc: error: unable to make temporary file: /tmp/bar: can't make unique filename: Permission denied *** [bar.o] Error code 1 Did some poking around in the clang source and it looks like it's doing some less than intelligent things when generating "temporary" paths (from contrib/llvm/tools/clang/lib/Driver/Driver.cpp ): 1598 std::string Driver::GetTemporaryPath(StringRef Prefix, const char *Suffix) 1599 const { 1600 // FIXME: This is lame; sys::Path should provide this function (in particular, 1601 // it should know how to find the temporary files dir). 1602 std::string Error; 1603 const char *TmpDir = ::getenv("TMPDIR"); 1604 if (!TmpDir) 1605 TmpDir = ::getenv("TEMP"); 1606 if (!TmpDir) 1607 TmpDir = ::getenv("TMP"); 1608 if (!TmpDir) 1609 TmpDir = "/tmp"; 1610 llvm::sys::Path P(TmpDir); 1611 P.appendComponent(Prefix); 1612 if (P.makeUnique(false, &Error)) { 1613 Diag(clang::diag::err_unable_to_make_temp) << Error; 1614 return ""; 1615 } 1616 1617 // FIXME: Grumble, makeUnique sometimes leaves the file around!? PR3837. 1618 P.eraseFromDisk(false, 0); 1619 1620 if (Suffix) 1621 P.appendSuffix(Suffix); 1622 return P.str(); This logic (line 1612) is racy and incorrect. This _needs_ to be fixed in clang to properly prefix and rename to the target path in the filesystem where the compilation is being done in order to avoid races with partial compilations, etc. Thanks, -Garrett From owner-freebsd-toolchain@FreeBSD.ORG Tue May 7 21:00:30 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 06964C34 for ; Tue, 7 May 2013 21:00:30 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by mx1.freebsd.org (Postfix) with ESMTP id C4EA51BD for ; Tue, 7 May 2013 21:00:29 +0000 (UTC) Received: by mail-ob0-f178.google.com with SMTP id 16so1025680obc.23 for ; Tue, 07 May 2013 14:00:29 -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=HbSdVVDEi0maLv0LJ3SVwF6VrfDkJ4a96aFR7vYrcH0=; b=D0OV7V8TX5ezD92MMG2smypHt+Dxf9yV1q3psPuPlHyz9i1iyC0kqcKyfxLgu64Ekh K4xf0F4sdChnfHF02QbZhPG8hsqGdCJT3AA+iTVH5Uk34FKtymWFhKJxpznc0Jh/dozT FmZrOZQc2ECXbqsXf5bNgt722WqR01BsFTQkuKzYMxzEA92cKBRCI8jN6VZ6zhQ6OryJ Bvv7/6WRwT0QnQyjaNd2ct0ZW+EKEaV9OVUNdsz93cY66xjUuPrZU8j/emtfSt5LPR3B Om64aRrgUVqOVl+93hMm/eKiA/a+x0ydXw9LuVUYGS+2u9o3ygUxgxklrIEh8VGeqJF5 3zrw== X-Received: by 10.60.133.242 with SMTP id pf18mr1051688oeb.80.1367960429409; Tue, 07 May 2013 14:00:29 -0700 (PDT) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id ns4sm6685388obc.2.2013.05.07.14.00.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 May 2013 14:00:28 -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: <2E2C2F74-A25B-4B9F-84C4-0A434B8C7EE6@gmail.com> Date: Tue, 7 May 2013 15:00:23 -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: ALoCoQmbvJTo5VvNGiLI2wrMcV5Ht2z+TVrUaR+liHJZRaqZA15Mp8td4XUUE6zO9REg//O9PDoY 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: Tue, 07 May 2013 21:00:30 -0000 On May 7, 2013, at 2:46 PM, Garrett Cooper wrote: > 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'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? >>=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 = 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 :). SRCDIR 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. Warner From owner-freebsd-toolchain@FreeBSD.ORG Tue May 7 21:08:07 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 15DD5D7A; Tue, 7 May 2013 21:08:07 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by mx1.freebsd.org (Postfix) with ESMTP id BE7A91F5; Tue, 7 May 2013 21:08:06 +0000 (UTC) Received: by mail-ve0-f176.google.com with SMTP id cz11so1081272veb.21 for ; Tue, 07 May 2013 14:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=CLyP2tGWkHLZ23vCEh7hPGgfZPW/c3aClhd0fsr9l4w=; b=Es8KB2x0zP7AdQRSAv+dvrXOgqlmoctSrXG9ItKkV3XAZTB9qerGeft+zEsloPL1AG WyxomKgGMqIzTTqW8dOisctzWf7mCT/GEqiSQps6eI1a1/rO3lkaJbImXxfvSikiPbOS g8zdvE9KBDGMBXxzi9UmC1+g/x4UKzr6Qcnmn46zvm54ja7HqMSk/AG6xTI12qVOg6fK yJkMKFkYeHDJOra5Qgob2SrYbRuVL+63xS29nPwz4zqtjEI5kMr4P4w2ArWUjpDcyWSW Nk1HQKvwA9Az0WZX2uHgQrFi1EGoYlN0VCR9Mu3NDd00bMDbSZKaL/djnD3UGbooVT1G pASA== MIME-Version: 1.0 X-Received: by 10.220.253.8 with SMTP id my8mr2555952vcb.23.1367960886362; Tue, 07 May 2013 14:08:06 -0700 (PDT) Received: by 10.220.141.72 with HTTP; Tue, 7 May 2013 14:08:06 -0700 (PDT) In-Reply-To: References: Date: Tue, 7 May 2013 14:08:06 -0700 Message-ID: Subject: Re: clang doesn't make temporary files in all instances, causes build races by not using mk*temp(3) in /tmp From: Garrett Cooper To: dim@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: toolchain@freebsd.org 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: Tue, 07 May 2013 21:08:07 -0000 On Tue, May 7, 2013 at 1:58 PM, Garrett Cooper wrote: > Hi Dimitriy, > I ran into the following error when trying to execute make > tinderbox with FreeBSD svn head with ATF changes I'm going to push to > benno@: > > cc -O -pipe -DHAVE_CONFIG_H > -I/scratch/freebsd/head-svn/gnu/lib/libgomp -I. > -I/scratch/freebsd/head-svn/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp > -I/scratch/freebsd/head-svn/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix > -std=gnu99 -Qunused-arguments -c > /scratch/freebsd/head-svn/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix/bar.c > -o bar.o > cc: error: unable to make temporary file: /tmp/bar: can't make unique > filename: Permission denied > *** [bar.o] Error code 1 > > Did some poking around in the clang source and it looks like it's > doing some less than intelligent things when generating "temporary" > paths (from contrib/llvm/tools/clang/lib/Driver/Driver.cpp ): > > 1598 std::string Driver::GetTemporaryPath(StringRef Prefix, const char *Suffix) > 1599 const { > 1600 // FIXME: This is lame; sys::Path should provide this function > (in particular, > 1601 // it should know how to find the temporary files dir). > 1602 std::string Error; > 1603 const char *TmpDir = ::getenv("TMPDIR"); > 1604 if (!TmpDir) > 1605 TmpDir = ::getenv("TEMP"); > 1606 if (!TmpDir) > 1607 TmpDir = ::getenv("TMP"); > 1608 if (!TmpDir) > 1609 TmpDir = "/tmp"; > 1610 llvm::sys::Path P(TmpDir); > 1611 P.appendComponent(Prefix); > 1612 if (P.makeUnique(false, &Error)) { > 1613 Diag(clang::diag::err_unable_to_make_temp) << Error; > 1614 return ""; > 1615 } > 1616 > 1617 // FIXME: Grumble, makeUnique sometimes leaves the file around!? PR3837. > 1618 P.eraseFromDisk(false, 0); > 1619 > 1620 if (Suffix) > 1621 P.appendSuffix(Suffix); > 1622 return P.str(); > > This logic (line 1612) is racy and incorrect. > This _needs_ to be fixed in clang to properly prefix and rename to > the target path in the filesystem where the compilation is being done > in order to avoid races with partial compilations, etc. And I was pointed to these awesome bug reports by someone internal to Isilon (thanks Anton!): - http://lists.cs.uiuc.edu/pipermail/llvmbugs/2012-August/024524.html - http://trac.macports.org/ticket/37834 It looks like the clang folks haven't fixed this issue yet. Arg.. Thanks, -Garrett From owner-freebsd-toolchain@FreeBSD.ORG Tue May 7 21:26:17 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 5B751EAE; Tue, 7 May 2013 21:26:17 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-bk0-x235.google.com (mail-bk0-x235.google.com [IPv6:2a00:1450:4008:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id 8E77C26D; Tue, 7 May 2013 21:26:16 +0000 (UTC) Received: by mail-bk0-f53.google.com with SMTP id i18so539727bkv.40 for ; Tue, 07 May 2013 14:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=YJriwf6hpu47VfHM4lgfIOvQ0JbuMWLQSk/niRU5zAI=; b=HyTh7rs9OKKd9aYMiZYFsXXM0YH63FQ7RmnveRlRzLowkgkBF1+uFE+cQCx7j6Uqj2 nn5uoCib9t8rRSoRhzLLNd3zwFkYah2RAfWemvIuVC2uWtt2Re0/geK2TbHZiOZkdeNK A9UB1BW/IqlO77hsxuWb/uCe3j9Pp9vyIl4QeHydK9ubD34U/UN2CAhTAHv5nLRsbMkD Yk0ozuCKxKV35Bvw5NMuNEHIoSoDqKxjN/QA8lW9+MKVx+16o6NfaA1tB2dfWboWo4tj s8JA2zwMIJnccfPJwmUQ744ncril3Rzf4NllQf1qLRnHX4YnW0SWHcalz9/v/37hAifi wfaQ== MIME-Version: 1.0 X-Received: by 10.204.226.80 with SMTP id iv16mr1076112bkb.48.1367961975281; Tue, 07 May 2013 14:26:15 -0700 (PDT) Received: by 10.204.225.206 with HTTP; Tue, 7 May 2013 14:26:15 -0700 (PDT) In-Reply-To: References: <20130507203906.GB40460@lor.one-eyed-alien.net> <2E2C2F74-A25B-4B9F-84C4-0A434B8C7EE6@gmail.com> Date: Tue, 7 May 2013 14:26:15 -0700 Message-ID: Subject: Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree From: Garrett Cooper To: Warner Losh Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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: Tue, 07 May 2013 21:26:17 -0000 On Tue, May 7, 2013 at 2:00 PM, Warner Losh wrote: > > On May 7, 2013, at 2:46 PM, Garrett Cooper wrote: > > > 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 sour= ce > >>> files that build upon each other or depend on sources located in othe= r > >>> 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 tha= t > 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 comm= it > 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 :). > > SRCDIR > EVARINUSE? 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} > 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. > 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. 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.. So all in all, I completely and wholeheartedly agree with your concerns. Thanks! -Garrett From owner-freebsd-toolchain@FreeBSD.ORG Tue May 7 21:56:03 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 C96A2365; Tue, 7 May 2013 21:56:03 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by mx1.freebsd.org (Postfix) with ESMTP id 8F112369; Tue, 7 May 2013 21:56:03 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUYl4bIyd/dlF2UjbXe53MXGPnvrltLcO@postini.com; Tue, 07 May 2013 14:56:03 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 7 May 2013 14:31:22 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r47LVIL03572; Tue, 7 May 2013 14:31:20 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 5277F58097; Tue, 7 May 2013 14:31:18 -0700 (PDT) To: Garrett Cooper Subject: Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree In-Reply-To: References: Comments: In-reply-to: Garrett Cooper message dated "Tue, 07 May 2013 13:05:07 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Tue, 7 May 2013 14:31:18 -0700 Message-ID: <20130507213118.5277F58097@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain Cc: 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: Tue, 07 May 2013 21:56:03 -0000 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 FWIW I've done this in the projects/bmake branch. 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). $ make -V '${SRCTOP OBJROOT OBJTOP .CURDIR .OBJDIR:L:@v@$v=${$v}@:ts\n}' SRCTOP=/b/sjg/work/FreeBSD/projects-bmake/src OBJROOT=/var/obj/projects-bmake/ OBJTOP=/var/obj/projects-bmake/amd64 .CURDIR=/b/sjg/work/FreeBSD/projects-bmake/src/bin/cat .OBJDIR=/var/obj/projects-bmake/amd64/bin/cat $ SRCTOP is simple to derrive from where sys.mk is found and the others can be deduced from that SRCTOP:= ${.PARSEDIR:H:H:tA} OBJROOT?= ${SRCTOP:H}/obj/ OBJTOP?= ${OBJROOT}${MACHINE} though since FreeBSD builds more than one MACHINE_ARCH per MACHINE (in some cases), OBJTOP?= ${OBJROOT}${MACHINE_ARCH} might make sense. For Junos we had the opposite - multiple MACHINEs with same MACHINE_ARCH. 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 OBJTOP= ${OBJROOT}${MACHINE}-${MACHINE_ARCH} but for cases like i386, amd64 you just get OBJTOP= ${OBJROOT}${MACHINE} as above. From owner-freebsd-toolchain@FreeBSD.ORG Wed May 8 03:25:47 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 CEA8DC39 for ; Wed, 8 May 2013 03:25:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by mx1.freebsd.org (Postfix) with ESMTP id A90AD147 for ; Wed, 8 May 2013 03:25:47 +0000 (UTC) Received: by mail-pd0-f181.google.com with SMTP id p11so893434pdj.26 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=Q7tCfpCbU5k1e5/SIqmgCG5eYbV0LmboPidFiDcN9N/zwJHOuvVNJzDUMGCW1Tl8gL AmDN2x/6jdWqEZJusarZr5GtwDs2m3Crr5VUNse9BuPm/XvqP8asjfB8+OkFavjUef9v v4AYE4BsOnYkwZA6gFdq+AeIfzFPz+8sSSFtTZz/rvzCdiIHtCG+GVw/JBsMgICoI+Zy GaXSeBnTf4ZQoIaI+A4vuE/FnqglkF5y/L8247sXTcqeMWkDpKJnxxlloxVhWAMIrzYp oS37AFSUPLKHkQy330jtNHXYnyTzwH5LK21NmlBnRHbM7VlUstnPub6PKa1D9ncVIxPH PuFg== 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: ALoCoQkpkMvX+kCDQvdn3C55CUisleR7wefvPU6cy+7z7prEDiti1lFv118DJnF13n7jhS26oX+x Cc: Garrett Cooper , 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 03:25:47 -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 From owner-freebsd-toolchain@FreeBSD.ORG Wed May 8 03:42:39 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A0729E6C; Wed, 8 May 2013 03:42:39 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by mx1.freebsd.org (Postfix) with ESMTP id 3C4451D7; Wed, 8 May 2013 03:42:38 +0000 (UTC) Received: by mail-vc0-f178.google.com with SMTP id kw10so1257739vcb.23 for ; Tue, 07 May 2013 20:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hiepuPno0za4+Yvm3t1p81TvkM5cnBxVi8LVK8ni0SU=; b=pxF4lvSjNSyFGjaeE05WLwfsqkM+e0SxWl45BwJrayQ8xOhErdXeNoJfLibc/XjnUE bwRCeBjmaXEm0noV32awG/dgX84q5oJot41tsk3pR8Bsjk/2s9kHYDeXbQmOa6Tg6NbB iUGHFIij64t4Gmea5H9UEtdhd3/do6T4lMF7aua7DKzez6HevYRKtleN6NuciiCRCkTd qxiohcfIdTpD6pvZ8lo10beL4H2/XGH5gfdJi3i7iUGdQtP/09k7DLoVoXUq5vnd0ZZX Qo+EEuwQpbhYILhH4CHHgNItjQ0V87+4C23KWMOEBqIx2RCRg0+pmRytZKufk9UDrWtS ykwA== MIME-Version: 1.0 X-Received: by 10.52.68.205 with SMTP id y13mr2710454vdt.33.1367984558233; Tue, 07 May 2013 20:42:38 -0700 (PDT) Received: by 10.52.31.194 with HTTP; Tue, 7 May 2013 20:42:38 -0700 (PDT) In-Reply-To: References: <20130507203906.GB40460@lor.one-eyed-alien.net> <2E2C2F74-A25B-4B9F-84C4-0A434B8C7EE6@gmail.com> Date: Tue, 7 May 2013 20:42:38 -0700 Message-ID: Subject: Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree From: Garrett Cooper To: Warner Losh Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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 03:42:39 -0000 On Tue, May 7, 2013 at 2:26 PM, Garrett Cooper wrote: > > On Tue, May 7, 2013 at 2:00 PM, Warner Losh wrote: > >> >> On May 7, 2013, at 2:46 PM, Garrett Cooper wrote: >> >> > 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 oth= er >> >>> 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 withi= n >> an >> >>> expected directory structure as well. >> >>> I haven't come up with a name, but was wondering if this was a goo= d >> >>> 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 com= mit >> 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 :). >> >> SRCDIR >> > > EVARINUSE? > > 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/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} > > >> 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. >> > > 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. > > 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.. > > So all in all, I completely and wholeheartedly agree with your concerns. > Oh sweet.. this is something to keep in mind too (from bsd.port.mk)... # SRC_BASE - The root of the src tree. (Some ports require this to ge= t # kernel sources). Default: /usr/src All else fails, ports has done it first -_-... Not the first var I've seen this done with... Thanks, -Garrett 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 From owner-freebsd-toolchain@FreeBSD.ORG Wed May 8 05:39:25 2013 Return-Path: Delivered-To: freebsd-toolchain@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" , "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: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= From owner-freebsd-toolchain@FreeBSD.ORG Wed May 8 05:47:20 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 06583A35; Wed, 8 May 2013 05:47:20 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by mx1.freebsd.org (Postfix) with ESMTP id 83E73796; Wed, 8 May 2013 05:47:17 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUYnm33E1UeIBfmGKPpNSfFv2pUVLpde8@postini.com; Tue, 07 May 2013 22:47:19 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 7 May 2013 22:41:22 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r485fML77620; Tue, 7 May 2013 22:41:22 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id DCA7258097; Tue, 7 May 2013 22:41:21 -0700 (PDT) To: Warner Losh Subject: Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree In-Reply-To: References: <20130507213118.5277F58097@chaos.jnpr.net> Comments: In-reply-to: Warner Losh message dated "Tue, 07 May 2013 21:25:37 -0600." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Tue, 7 May 2013 22:41:21 -0700 Message-ID: <20130508054121.DCA7258097@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain Cc: Garrett Cooper , 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:47:20 -0000 On Tue, 7 May 2013 21:25:37 -0600, Warner Losh writes: >where does MAKEOBJDIRPREFIX come into play? I don't normally use it, it is a handy but rather crude implement. I normally use MAKEOBJDIR='${.CURDIR:S,${SRCTOP},${OBJTOP},}' which gives you a similar - but much neater result than MAKEOBJDIRPREFIX. >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). Yes, which is why I'm adjusting accordingly. >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. >Why is this gratuitously different than the current scheme? 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 projects/bmake branch is about showing how freebsd can be built in meta mode. The tree dependencies are represented as dir.target_spec >would I build a pc98 build with this? And why have it be different for = 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). From owner-freebsd-toolchain@FreeBSD.ORG Wed May 8 15:13:25 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A67EF987; Wed, 8 May 2013 15:13:25 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by mx1.freebsd.org (Postfix) with ESMTP id 78E286B4; Wed, 8 May 2013 15:13:25 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id fa10so1392335pad.5 for ; Wed, 08 May 2013 08:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ohPypBm4YXYR9QzrU9HLycY7uSjhdsnJjOKx1np9M/Y=; b=aV1G7lCZHGf0UqlHZt1GkWkq9DtYkP0XWXullbYmuZ9zEqzOVrp94jGrsZuhcfQvt3 qzilmYKCk8QfuWht/J+JtRYXdytfK9vb5F3DMcijC1c5jqVWcCb8euc8zx8XV/2CoVIn xLcfljo7BTXiIZ22T9Uhu1g20IQ2wDBZyH2AJaFApkB8xIrFJP8sD8Z5Jw/XI7Z3D0P5 fZWTIawvqFUIv+kAWkJkzYaT5dvZbcqqE+fg/IFUbFKuzao4K7o0kZnaoWgRWSP2xQ7R 3wcDuETdiB0BwnJRG74sU5GAjf0j3lJlvu7Vh/Apvtg5LDtcorGIBiVH/Lob2q4TiSu8 R8LA== X-Received: by 10.68.212.35 with SMTP id nh3mr8049997pbc.40.1368025999873; Wed, 08 May 2013 08:13:19 -0700 (PDT) Received: from [192.168.20.5] (c-98-203-241-95.hsd1.wa.comcast.net. [98.203.241.95]) by mx.google.com with ESMTPSA id c5sm32947518pbl.37.2013.05.08.08.13.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 May 2013 08:13:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) Subject: Fwd: conf/178421: [PATCH] compile_et needs to be built with bootstrap-tools for buildworld when WITH_KERBEROS is set From: Garrett Cooper Date: Wed, 8 May 2013 08:13:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <728A985E-4118-4CB9-B61F-40BB32B928A4@gmail.com> References: <201305081510.r48FA0lL013761@freefall.freebsd.org> To: Brooks Davis X-Mailer: Apple Mail (2.1283) Cc: toolchain@freebsd.org, Benno Rice 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 15:13:25 -0000 FYI... I hit this pretty quickly when doing make tinderbox on my = VM with a minimally tainted svn tree, so this probably should be fixed = ASAP. If someone could please do this, I would be grateful (I've hit = this before, but my memory is a bit short-term about some things and it = got lost when I was migrating local modifications in the past). Thanks! -Garrett Begin forwarded message: > From: FreeBSD-gnats-submit@FreeBSD.org > Subject: Re: conf/178421: [PATCH] compile_et needs to be built with = bootstrap-tools for buildworld when WITH_KERBEROS is set > Date: May 8, 2013 8:10:00 AM PDT > To: Garrett Cooper > Reply-To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org >=20 > Thank you very much for your problem report. > It has the internal identification `conf/178421'. > The individual assigned to look at your > report is: freebsd-bugs.=20 >=20 > You can access the state of your problem report at any time > via this link: >=20 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D178421 >=20 >> Category: conf >> Responsible: freebsd-bugs >> Synopsis: [PATCH] compile_et needs to be built with = bootstrap-tools for buildworld when WITH_KERBEROS is set >> Arrival-Date: Wed May 08 15:10:00 UTC 2013 From owner-freebsd-toolchain@FreeBSD.ORG Wed May 8 21:49:17 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AE78ED48 for ; Wed, 8 May 2013 21:49:17 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-vb0-x22a.google.com (mail-vb0-x22a.google.com [IPv6:2607:f8b0:400c:c02::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 6D57BF18 for ; Wed, 8 May 2013 21:49:17 +0000 (UTC) Received: by mail-vb0-f42.google.com with SMTP id w16so2057906vbf.15 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=IPjBfEE/JX1mEyHttvuLBxR8v5b6eDmtonO7KIINVJduNGOCVKFe1v4vTKPCkxSijY 9SLjAvXKqKluBLGWwfDLSSs/QmrKnAKJiuX9u+fjraLxRKQz44mZPMYiwge1IRuPhQL1 gIu74q8JUeoiRe2/3SFRWXL8z02YTHBK7x2+qKrw8+ZrLU5eVJWnJzVuS55jowncMIXx IvIiZ4fnPE2kQqVrqAGaWm+2bbf0yHvNxbsiNIlitqUdG6tUecshDri3B5MSD7+o6de/ Z9zqlw63DHwHm1JpDsD8Ut6YCz8b8WSGaxmIWiYqfEegOg/fkfu1WP5WwZ0yLNQJgzZX tk0Q== 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: ALoCoQl5lId6Dsx0o6LqkcaD0eGuPUJE57hdBBndGn6ihCfB+fJZJvKZAr74OYbZcxN+Gxisj1XN Cc: Garrett Cooper , 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 21:49:17 -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 From owner-freebsd-toolchain@FreeBSD.ORG Wed May 8 23:01:33 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 81120289; Wed, 8 May 2013 23:01:33 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by mx1.freebsd.org (Postfix) with ESMTP id 19D111CC; Wed, 8 May 2013 23:01:30 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUYrZSlgTrgeHWUWN4bxmccz3Iv9a+Jyz@postini.com; Wed, 08 May 2013 16:01:33 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 8 May 2013 15:53:03 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r48Mr3L23585; Wed, 8 May 2013 15:53:03 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id DF7AE58097; Wed, 8 May 2013 15:53:02 -0700 (PDT) To: Warner Losh Subject: Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree In-Reply-To: <9CD1CE3E-C17C-4C63-BA03-190531185D7A@bsdimp.com> References: <20130507213118.5277F58097@chaos.jnpr.net> <20130508054121.DCA7258097@chaos.jnpr.net> <9CD1CE3E-C17C-4C63-BA03-190531185D7A@bsdimp.com> Comments: In-reply-to: Warner Losh message dated "Wed, 08 May 2013 15:49:12 -0600." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Wed, 8 May 2013 15:53:02 -0700 Message-ID: <20130508225302.DF7AE58097@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain Cc: Garrett Cooper , 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 23:01:33 -0000 On Wed, 8 May 2013 15:49:12 -0600, Warner Losh writes: >> 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 = No. MAKEOBJDIRPREFIX gives you an objdir by simply doing ${MAKEOBJDIRPREFIX}${.CURDIR} this is very quick and handy, but the paths can be very long and ugly if you happen to be on automounted nfs. For the sake of discussion assume I am in /.amd/server/b/sjg/work/FreeBSD/current/src/bin/cat MAKEOBJDIRPREFIX=/var/obj/current/$MACHINE make -V .OBJDIR /var/obj/current/amd64/.amd/server/b/sjg/work/FreeBSD/current/src/bin/cat MAKEOBJDIR='${.CURDIR:S,${SRCTOP},${OBJTOP},}' make -V .OBJDIR /var/obj/current/amd64/bin/cat (assuming of course that OBJTOP='${OBJROOT}${MACHINE}' as previously mentioned). The ability to do the above is something I added to NetBSD's make ages ago because we found that MAKEOBJDIRPREFIX resulted in pathnames that were blowing the command line limits on FreeBSD 2.x >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 = Yes, MAKEOBJDIRPREFIX is certainly very handy - and I use it for quick & dirty builds and of course for buildworld and such. >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 = What trick? MAKEOBJDIRPREFIX has always worked as you describe. Don't confuse limitations imposed by makefiles as being limitations of the tool ;-) >The project currently uses dots without issue. Not quite sure why you'd = The project doesn't currently do anything close to what dirdeps.mk allows. From owner-freebsd-toolchain@FreeBSD.ORG Thu May 9 05:13:39 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 E4A998DF; Thu, 9 May 2013 05:13:39 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by mx1.freebsd.org (Postfix) with ESMTP id A49841D93; Thu, 9 May 2013 05:13:39 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUYswg0wwq4joRc0PhASxdYIEe6Mk3MsU@postini.com; Wed, 08 May 2013 22:13:39 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 8 May 2013 21:58:34 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r494wYL13752; Wed, 8 May 2013 21:58:34 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 2E67058097; Wed, 8 May 2013 21:58:34 -0700 (PDT) To: Warner Losh Subject: Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree In-Reply-To: <9CD1CE3E-C17C-4C63-BA03-190531185D7A@bsdimp.com> References: <20130507213118.5277F58097@chaos.jnpr.net> <20130508054121.DCA7258097@chaos.jnpr.net> <9CD1CE3E-C17C-4C63-BA03-190531185D7A@bsdimp.com> Comments: In-reply-to: Warner Losh message dated "Wed, 08 May 2013 15:49:12 -0600." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Wed, 8 May 2013 21:58:34 -0700 Message-ID: <20130509045834.2E67058097@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain Cc: Garrett Cooper , 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: Thu, 09 May 2013 05:13:40 -0000 >> Do you mean why not simply use ${MACHINE}.${MACHINE_ARCH} always? >> Encoding both MACHINE and MACHINE_ARCH always is doable, but I avoid = >'.' Actually I only avoid '.' in the captured dirdeps. So ${MACHINE}.${MACHINE_ARCH} in objdir may be ok - will take a look. Dealing with ${MACHINE}.${MACHINE_ARCH} is actually easy it just gets stripped from the captured dirdeps, it is references to other machine and arch's that need to be captured but cannot be dealt with as neatly. The vast majority of such cases though are for pseudo machines like "host" and "common" (for generated files which are machine independent) where the issue shouldn't arise anyway.