git: f4d987cd137c - main - mk: WITH_FOO=no now generates a warning

Rodney W. Grimes freebsd at gndrsh.dnsmgr.net
Thu Jun 10 19:48:53 UTC 2021


> On Thu, Jun 10, 2021 at 5:46 AM Rodney W. Grimes <freebsd at gndrsh.dnsmgr.net>
> wrote:
> 
> > > The branch main has been updated by imp:
> > >
> > > URL:
> > https://cgit.FreeBSD.org/src/commit/?id=f4d987cd137cb2d0d54a3e35d9258ca7c175d291
> > >
> > > commit f4d987cd137cb2d0d54a3e35d9258ca7c175d291
> > > Author:     Warner Losh <imp at FreeBSD.org>
> > > AuthorDate: 2021-06-10 00:10:12 +0000
> > > Commit:     Warner Losh <imp at FreeBSD.org>
> > > CommitDate: 2021-06-10 00:10:52 +0000
> > >
> > >     mk: WITH_FOO=no now generates a warning
> >
> > First off thank you, this may stop some head scratching!
> >
> > But what about WITHOUT_foo=no the symetrical mistake?
> > I see bdrewey raised this in the review, but it was dismissed
> > using the argument that some languages, spanish specifically,
> > allow double negatives.  This is computers engineering,
> > and in that field of science double negatives are clearly
> > defined and understood, so using an argument of a language
> > that simply does not apply to the field, IMHO, is an arguement
> > of low standing.
> >
> 
> It's not the same, and I'm not solving that error because the mapping
> is ambiguous. I've seen a lot more instances of people using
> WITHOUT_FOO=no unironically because it makes sense to the
> person doing it. I disagree it's not a language issue, because
> language is involved here: how do we assign semantic meaning
> is unclear and I have no desire to get involved in what I clearly
> view as a quagmire.
> 
> 
> > Also I do not believe == is a case insensitive operation
> > so this code fails for NO, No, and nO(sic).
> >
> 
> Also true. Again, this isn't perfect. I have no desire to make it
> perfect, because the list isn't finite.
> 
> If you'd like to own this issue, feel free, but it's not something I
> wish to pursue further.

You touched it, you own it.

> Warner
> 
> 
> > Regards,
> > Rod
> > >
> > >     Many people are used to gnu configure's behavior of changing
> > >     --with-foo=no to --without-foo. At the same time, several folks have
> > >     WITH_FOO=no in their config files to enable this ironic form of the
> > >     option because of an old meme from IRC, a mailing list or the forums
> > (I
> > >     forget which). Add a warning to allow to alert people w/o breaking
> > POLA.
> > >
> > >     Reviewed by:            allanjude, bdrewery, manu
> > >     MFC After:              2 weeks
> > >     Sponsored by:           Netflix
> > >     Differential Revision:  https://reviews.freebsd.org/D30684
> > > ---
> > >  share/mk/bsd.mkopt.mk | 6 ++++++
> > >  1 file changed, 6 insertions(+)
> > >
> > > diff --git a/share/mk/bsd.mkopt.mk b/share/mk/bsd.mkopt.mk
> > > index 5a9cf1b2f1be..98d23dd46c2a 100644
> > > --- a/share/mk/bsd.mkopt.mk
> > > +++ b/share/mk/bsd.mkopt.mk
> > > @@ -36,6 +36,9 @@
> > >  #
> > >  .for var in ${__DEFAULT_YES_OPTIONS}
> > >  .if !defined(MK_${var})
> > > +.if defined(WITH_${var}) && ${WITH_${var}} == "no"
> > > +.warning "Use WITHOUT_${var}=1 insetad of WITH_${var}=no"
> > > +.endif
> > >  .if defined(WITHOUT_${var})                  # WITHOUT always wins
> > >  MK_${var}:=  no
> > >  .else
> > > @@ -54,6 +57,9 @@ MK_${var}:= yes
> > >  #
> > >  .for var in ${__DEFAULT_NO_OPTIONS}
> > >  .if !defined(MK_${var})
> > > +.if defined(WITH_${var}) && ${WITH_${var}} == "no"
> > > +.warning "Use WITHOUT_${var}=1 insetad of WITH_${var}=no"
> > > +.endif
> > >  .if defined(WITH_${var}) && !defined(WITHOUT_${var}) # WITHOUT always
> > wins
> > >  MK_${var}:=  yes
> > >  .else
> > >
> >
> > --
> > Rod Grimes
> > rgrimes at freebsd.org
> >

-- 
Rod Grimes                                                 rgrimes at freebsd.org


More information about the dev-commits-src-all mailing list