conf/181116: CURRENT build always uses bmake, even though WITHOUT_BMAKE is specified
Garrett Cooper
yaneurabeya at gmail.com
Wed Aug 7 18:30:02 UTC 2013
The following reply was made to PR conf/181116; it has been noted by GNATS.
From: Garrett Cooper <yaneurabeya at gmail.com>
To: "Simon J. Gerraty" <sjg at juniper.net>
Cc: "FreeBSD-gnats-submit at FreeBSD.org" <FreeBSD-gnats-submit at FreeBSD.org>,
"freebsd-bugs at FreeBSD.org" <freebsd-bugs at FreeBSD.org>
Subject: Re: conf/181116: CURRENT build always uses bmake, even though WITHOUT_BMAKE is specified
Date: Wed, 7 Aug 2013 11:24:15 -0700
On Aug 7, 2013, at 10:51 AM, "Simon J. Gerraty" <sjg at juniper.net> wrote:
>=20
> src/Makefile does not read bsd.own.mk so does not see src.conf
> it does however see make.conf
Ah, but src.conf controls WITH* (and the option is documented in the manage,=
along with all the others). You accidentally broke POLA :(.
> More importantly, is this a "test" or is there a percieved need to
> continue building with fmake? If so why?
I gave up waiting for bmake and all the associated infrastructure to be back=
ported to stable/9 (and I know there's a snowball's chance in hades that it'=
ll be backported to stable/8), so I figured out how to make the test infrast=
ructure work independent of bmake.
> I was aiming to get rid of WITH[OUT]_BMAKE soon - in time for 10.0
This is a really bad idea. The fact that bmake causes conf/179111 without a m=
itigation strategy is reason alone to leave this knob in because I don't tru=
st all makefiles that exist outside of FreeBSD to work sanely without set -e=
. Heck, a lot of the Makefile snippets in FreeBSD don't behave sanely withou=
t set -e, as noted in the bug (and those are just a handful).
Management at $work would agree that it makes no sense wasting engineering h=
ours chasing down build faults.=
More information about the freebsd-bugs
mailing list