Re: buildkernel failure because ctfconvert not installed

On Fri, Apr 10, 2020, 11:36 AM Rodney W. Grimes <
freebsd-rwg_at_gndrsh.dnsmgr.net> wrote:

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

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