From owner-freebsd-bugs@FreeBSD.ORG Thu Sep 5 18:58:13 2013 Return-Path: Delivered-To: freebsd-bugs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 425DB1FA; Thu, 5 Sep 2013 18:58:13 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0016B290E; Thu, 5 Sep 2013 18:58:09 +0000 (UTC) Received: from mail2-ch1-R.bigfish.com (10.43.68.225) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.22; Thu, 5 Sep 2013 18:58:03 +0000 Received: from mail2-ch1 (localhost [127.0.0.1]) by mail2-ch1-R.bigfish.com (Postfix) with ESMTP id 1174226036E; Thu, 5 Sep 2013 18:58:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz1de097hz2fh2a8h839hd25hf0ah1288h12a5h12a9h12bdh12e5h137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1758h1898h18e1h1946h19b5h1ad9h1b0ah1b2fh1b88h1fb3h1d0ch1d2eh1d3fh1de2h1dfeh1dffh1e23h1fe8h1ff5h1155h) Received-SPF: pass (mail2-ch1: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=sjg@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail2-ch1 (localhost.localdomain [127.0.0.1]) by mail2-ch1 (MessageSwitch) id 137840748198179_14325; Thu, 5 Sep 2013 18:58:01 +0000 (UTC) Received: from CH1EHSMHS003.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244]) by mail2-ch1.bigfish.com (Postfix) with ESMTP id 0FBA920040; Thu, 5 Sep 2013 18:58:01 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.50) by CH1EHSMHS003.bigfish.com (10.43.70.3) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 5 Sep 2013 18:58:00 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 5 Sep 2013 11:57:59 -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 r85IvwL89221; Thu, 5 Sep 2013 11:57:58 -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 7D04D5807E; Thu, 5 Sep 2013 11:57:58 -0700 (PDT) To: Alexey Dokuchaev Subject: Re: bin/178819: bmake w/ WRKDIRPEFIX=/tmp breaks Ports Collection In-Reply-To: <20130905175936.GB58718@FreeBSD.org> References: <201309030703.r8373BSU072280@freefall.freebsd.org> <20130905164552.3639E5807E@chaos.jnpr.net> <20130905175936.GB58718@FreeBSD.org> Comments: In-reply-to: Alexey Dokuchaev message dated "Thu, 05 Sep 2013 17:59:36 -0000." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Thu, 5 Sep 2013 11:57:58 -0700 Message-ID: <20130905185758.7D04D5807E@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: freebsd-bugs@FreeBSD.ORG X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 18:58:13 -0000 On Thu, 5 Sep 2013 17:59:36 +0000, Alexey Dokuchaev writes: >Yes, I've seen the fresh import; will test it tomorrow. I'm not sure what >is the problem, but "ports should be able to control the value of MAKEFILE >as desired" looks strange. MAKEFILE is one of the standard bsd.port.mk's bmake treats MAKEFILE the same way old sysV make did, it gets set to the name of the [mM]akefile read. This is obviously something fmake never did, and ports relies on being able to set the variable. The new version of bmake allows for both behaviors by using an internal context for the sysV behavior. If the makefiles explicitly set a value for MAKEFILE, that overrides the one that bmake itself would set. >something else (e.g. internal bmake(1)'s variable)? And how does this all >got affected by WRKDIRPREFIX=/tmp? I don't know - the PR body described a different issue - which clearly needed fixing.