From owner-freebsd-current@freebsd.org Fri Apr 10 17:52:44 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 5CBBE2C4507 for ; Fri, 10 Apr 2020 17:52:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 48zQb00rfyz4MJK for ; Fri, 10 Apr 2020 17:52:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.nyi.freebsd.org (Postfix) id 1C7D22C4506; Fri, 10 Apr 2020 17:52:44 +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 1C3D92C4505 for ; Fri, 10 Apr 2020 17:52:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48zQZz27RMz4MJH for ; Fri, 10 Apr 2020 17:52:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qv1-xf33.google.com with SMTP id ef12so1285666qvb.11 for ; Fri, 10 Apr 2020 10:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B0KVA2BIgpglOXf/esDZmSCnLbHyTnLzTWh7rXR5M+g=; b=G3Bd+pYeLYifgpzGxNq/Mjj+SDx12M2sgdrT7gwk8kXWDFqum2OZO6+azY19ZDKhNU o5uS+XniWs63Oaijr8EEhPCWORSpiO0m+OAWXONhAz6O7MyEbY3TsNvXw1+iMxJhBZhW 14bB5A+G3BOSA9vHdMTtuQbey0KhyrUPTwNHfehnDyeFnfn2PfO6ThRwiSL+BNGMVM88 GROkbSjHmeLTlRRhUmB4BNz8gUAr/9wUyMbPrEfEyd9zT9B80+Xxde9FF85N/5lTZAhl 406Lz2YZgC2xVIbL0cQ/juOn34vPbkb28C1py2VEuC67E3ncqrnhHHUugIVnEIFoMcB1 uTsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B0KVA2BIgpglOXf/esDZmSCnLbHyTnLzTWh7rXR5M+g=; b=A53FfXKoQqp8zqsg37AbU3l+b81UtdGOCrvGMQCwaITo9Q+j7MvpqLb/JbK+MkOZ8a 9nNzP1NWneWhM3p/sqIsCg6K79QVU6hcGMfJeWwgb+xXmgmS9vzY/JA+NP4XJk8I1HCQ CCMJA0SakA74VNcjpurKu1oxYX55qyHAfHuWQ/12vAWulgMgtnYV7jmFqfaJTC6gv4k1 Calnewb6VPSucB/pLLaXtAYF+jxtYAITuAHtgGWLcynG8KnFz9K+qBW8oMjfgmVfLBk2 tIzmJbXgSiNBCuQWUVYIGVmDEzp9dBepwFXiI6HGrMf9nrAfBagdQKR9F3Xj2iY8w+Hc 9cZA== X-Gm-Message-State: AGi0Pub/B6z+FWLUD+X+TJtbMRhhydwZFYHDVaBcqe8jYR1L/QpQIAjT f0yBSOvcPUjD22wlWnOgL9xBS51BBbQbctJKdxTagg== X-Google-Smtp-Source: APiQypLcCmBWkdsQxG9cyYHO8Tc3OpB4bizfw6m5ejwgff7I5LizrQtN7JzseuCdMR9B85lgWHWbOv+qwxVEw1SdI6M= X-Received: by 2002:a0c:b905:: with SMTP id u5mr6236519qvf.125.1586541161778; Fri, 10 Apr 2020 10:52:41 -0700 (PDT) MIME-Version: 1.0 References: <202004101736.03AHaOAp016744@gndrsh.dnsmgr.net> In-Reply-To: <202004101736.03AHaOAp016744@gndrsh.dnsmgr.net> From: Warner Losh Date: Fri, 10 Apr 2020 11:52:29 -0600 Message-ID: Subject: Re: buildkernel failure because ctfconvert not installed To: "Rodney W. Grimes" Cc: Poul-Henning Kamp , Yuri Pankov , =?UTF-8?Q?Trond_Endrest=C3=B8l?= , Gary Jennejohn , FreeBSD Current X-Rspamd-Queue-Id: 48zQZz27RMz4MJH X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=G3Bd+pYe; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::f33) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.43 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[3.3.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-1.43)[ip: (-6.33), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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:52:44 -0000 On Fri, Apr 10, 2020, 11:36 AM Rodney W. Grimes < freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > 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. > No. We should not. That breaks other people. > > > > > > > >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. > Time is relevant. > > > > 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. > It's not 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*** > I didn't read the docs and things broke. > > > > > > > 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. > It takes them time to find out why the documented thing has changed. 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. > Not sure this would be popular. Lots of places set some value. This would be way worse. > > > We almost certainly are not going to change this. > Your position, others are free to disagree, as I do. > Others haven't been maintaining the build system. Others didn't carefully negotiate the current behavior among different warring factions as a compromise everyone was happy with. Others haven't been working for 20 years to keep it consistent. So while it is just an opinion, it's one that's informed by long experience with many different issues and scenarios that have come up over time. > 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". > I've seen no code. I can't say for sure without looking at the code proposed. Warner > Warner > -- > Rod Grimes > rgrimes@freebsd.org >