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.


> > >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 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.

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).


> > 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.

We almost certainly are not going to change this. 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.

Warner