Date: Sat, 25 May 2013 02:01:46 +0000 From: "+a-#+3-d+c-v+:-.+@-=+w-x@s.a@d.e@e.k@x.y@g.h@h.i@p.q@k.m" <jesse@glx.me> To: obrien@freebsd.org, freebsd-current@freebsd.org Subject: Re: Unexpected behavior change [FreeBSD]make -> bmake Message-ID: <CAEMuk58YSzC92hYMUtmeKnzCyqow1i69HoGbf91zS0uweHP6wg@mail.gmail.com> In-Reply-To: <20130524010315.GA83715@dragon.NUXI.org> References: <20130524010315.GA83715@dragon.NUXI.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Using bmake in ports instead of building it into base system. On Fri, May 24, 2013 at 1:03 AM, David O'Brien <obrien@freebsd.org> wrote: > For some reason bmake is now using share/mk/ from within a source tree > instead of the installation in /usr/share/mk/: > > /w/10/usr.bin/xinstall$ bmake > bmake: "/b/deo/10/share/mk/bsd.own.mk" line 444: MK_BMAKE can't be set > by a user. > > I believe this is against POLA as there is no guarantee that a share/mk/ > within the source tree is parseable by the invoked /usr/bin/bmake. It is > /usr/share/mk/ that is guaranteed to be consistent with /usr/bin/make. > > I see this as synonymous with using headers from lib/libc/ within the > source tree vs. /usr/include (which match the /lib/libc.so) when > building in this same way. I think we can all agree that is wrong > (the headers that match the libc that is being linked against needs > to be used). > > Can we go back to the pre-16-May-2013 behavior? > > -- > -- David (obrien@FreeBSD.org) > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- (c) http://glx.me/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAEMuk58YSzC92hYMUtmeKnzCyqow1i69HoGbf91zS0uweHP6wg>