Re: buildkernel failure because ctfconvert not installed

> On Fri, Apr 10, 2020 at 10:45 AM Rodney W. Grimes <
> freebsd-rwg_at_gndrsh.dnsmgr.net> wrote:
> 
> > > --------
> > > In message <9f03fb79-a0ad-3c11-9a50-bc7731882da9_at_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_at_freebsd.org