Date: Thu, 5 Sep 2013 11:57:58 -0700 From: "Simon J. Gerraty" <sjg@juniper.net> To: Alexey Dokuchaev <danfe@FreeBSD.ORG> Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: bin/178819: bmake w/ WRKDIRPEFIX=/tmp breaks Ports Collection Message-ID: <20130905185758.7D04D5807E@chaos.jnpr.net> In-Reply-To: <20130905175936.GB58718@FreeBSD.org> References: <201309030703.r8373BSU072280@freefall.freebsd.org> <20130905164552.3639E5807E@chaos.jnpr.net> <20130905175936.GB58718@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130905185758.7D04D5807E>