On 03/11/15 17:38, Brooks Davis wrote: > On Wed, Mar 11, 2015 at 11:21:17AM +0100, Hans Petter Selasky wrote: >> Hi, >> >> When installing bmake from ports, the binary ends up in /usr/local/bin >> and our top-level Makefile doesn't check there: >> >> diff --git a/Makefile b/Makefile >> index e89a5b1..35ade48 100644 >> --- a/Makefile >> +++ b/Makefile >> _at__at_ -129,7 +129,7 _at__at_ TGTS+= ${BITGTS} >> .ORDER: buildkernel reinstallkernel >> .ORDER: buildkernel reinstallkernel.debug >> >> -PATH= /sbin:/bin:/usr/sbin:/usr/bin >> +PATH= /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin >> >> >>> bmake -m $PWD/share/mk buildkernel >>> env: bmake: No such file or directory >>> bmake: "/usr/img/freebsd/Makefile" line 136: warning: "/usr/bin/env -i PATH=/sbin:/bin:/usr/sbin:/usr/bin bmake __MAKE_CONF=/etc/make.conf -f /dev/null -V MAKEOBJDIRPREFIX dummy" returned non-zero status >>> --- buildkernel --- >>> --- buildkernel --- >>> ERROR: Missing kernel configuration file(s) (NOIP). >>> *** [buildkernel] Error code 1 >>> >> >> Any objections against extending the PATH= in our top-level Makefile? > > I can't express how bad I think that idea is. You should be able to just use > a full path to the installed bmake. I'm surprised you need -m. > Hi, You can see the PATH environment variable is overwritten by what is inside the top-level Makefile. And "which bmake" reports /usr/local/bin/bmake and that is not inside the binary searching path, when the Makefile invokes bmake again. I was surprised too to see this! --HPSReceived on Wed Mar 11 2015 - 15:55:25 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:56 UTC