buildkernel failure because ctfconvert not installed
Rodney W. Grimes
freebsd-rwg at gndrsh.dnsmgr.net
Fri Apr 10 17:36:28 UTC 2020
> 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
More information about the freebsd-current
mailing list