From owner-freebsd-current@freebsd.org Fri Apr 10 17:36:28 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D3DC22C39B8 for ; Fri, 10 Apr 2020 17:36:28 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 48zQDD4CL2z4Kt7 for ; Fri, 10 Apr 2020 17:36:28 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: by mailman.nyi.freebsd.org (Postfix) id 905D42C39B7; Fri, 10 Apr 2020 17:36:28 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 901CE2C39B6 for ; Fri, 10 Apr 2020 17:36:28 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48zQDC58WHz4Kt6 for ; Fri, 10 Apr 2020 17:36:27 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 03AHaOAd016745; Fri, 10 Apr 2020 10:36:24 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 03AHaOAp016744; Fri, 10 Apr 2020 10:36:24 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202004101736.03AHaOAp016744@gndrsh.dnsmgr.net> Subject: Re: buildkernel failure because ctfconvert not installed In-Reply-To: To: Warner Losh Date: Fri, 10 Apr 2020 10:36:24 -0700 (PDT) CC: "Rodney W. Grimes" , Poul-Henning Kamp , Yuri Pankov , =?UTF-8?Q?Trond_Endrest=C3=B8l?= , Gary Jennejohn , FreeBSD Current X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 48zQDC58WHz4Kt6 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [-0.35 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.66)[-0.663,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.62)[-0.620,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_SEVEN(0.00)[7]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.03)[ip: (0.13), ipnet: 69.59.192.0/19(0.06), asn: 13868(0.03), country: US(-0.05)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2020 17:36:28 -0000 > On Fri, Apr 10, 2020 at 10:45 AM Rodney W. Grimes < > freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > > > -------- > > > In message <9f03fb79-a0ad-3c11-9a50-bc7731882da9@fastmail.com>, Yuri > > Pankov writes: > > > >Trond Endrest?l wrote: > > > >> On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote: > > > >> > > > >>> OK, I figured it out. > > > >>> > > > >>> I used to have MK_CTF=no in src.conf, but I recently changed it to > > > >>> WITH_CTF=no. > > > >> > > > >> It's either WITH_xxx=yes or WITHOUT_xxx=yes > > > > It's either -DWITH_FOO or -DWITHOUT_FOO. yes or no never enters into it. Then we *COULD*, maybe even *SHOULD* check for a value and complain if one is set. > > > > > >Or even WITH_xxx= or WITHOUT_xxx=, src.conf(5) explicitly states that > > > >value is NOT checked: > > > > > > > >The values of variables are ignored regardless of their setting; even > > if > > > > they would be set to "FALSE" or "NO". The presence of an option > > > >causes it to be honored by make(1). > > > > > > That is not even close to POLA-compliance... > > > > It took 20 years for someone to notice. If it takes 20 years to be > astonished, I suspect that it comes close to 'least' by any sane measure. I do not see the word *recent* in POLA. As far as I can tell POLA is time invariant. > > > I am not a fan of it either, not sure when this idea came about > > of doing WITH_ and WITHOUT and ignoring the set value, but it > > is very non POLA given how many variables we do have with set values. > > > > We've literally ignored the value for the last 20 years or so (we started > in the 4.x time frame). This is the first time it's come up. It's hard to > make a convincing POLA argument based on this data. Wrong or bad for 20 years makes it no less wrong. > We specifically ignored it because we had crazy s*** in the tree like > NOSHARED=no meaning something. And it wasn't quite the something you'd > think it would mean without careful study (it meant do link this shared, > which is straight forward enough. But it didn't mean do create this library > as shared). What you call crazy s*** is just double negatives, and though it is poor it actually has clear symantics. You want crazy s*** WITH_xxx=yes WITH_xxx=no do exactly the same thing! Now thats crazy s*** > > > > > Obviously negative values ("false", "no") should either be reported as > > > errors or preferably be respected. > > > > You can't make something foolproof because fools are so ingenious. Also, > turns out it's trickier to "fix" than you might think. It really isnt hard to fix... just stop using, then later allowing a value on WITH_xxx or WITHOUT_xxx. Right now we could add a warning if a value is set, people would slowly weed out this poor use, and in time up the warning to an error. > > We almost certainly are not going to change this. Your position, others are free to disagree, as I do. > Why aren't we going to > change it? It took 20 years for someone to complain and it may break > currently working scripts that rely on the documented behavior of the > variable being defined to define WITH_FOO=n for some crazy reason. And > this isn't a theoretical example, I know of at least two build systems that > define WITH_FOO or WITHOUT_FOO to some value. Also, does WITHOUT_FOO=no > mean "I don't want foo"? or "I don't not want foo?" So if you don't do it > for WITHOUT but do to it for WITH, you wind up with another mess of > inconsistency, or you wind up getting close to have NOSHARED=no again. See proposed "change and fix". > Warner -- Rod Grimes rgrimes@freebsd.org