Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 1 Feb 2021 02:48:12 -0800
From:      Mark Millard <marklmi@yahoo.com>
To:        "arichardson@freebsd.org" <arichardson@FreeBSD.org>, dev-commits-src-main@freebsd.org
Subject:   Re: git: 7fa2f2a62f04 - main - Rename NO_WERROR -> MK_WERROR=no
Message-ID:  <9110AE5B-4BC0-4BF0-A33E-5E1C78224B9E@yahoo.com>
References:  <9110AE5B-4BC0-4BF0-A33E-5E1C78224B9E.ref@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> On Sun, 31 Jan 2021 at 19:12, Antoine Brodin <antoine at freebsd.org> =
wrote:
> >
> > On Sun, Jan 10, 2021 at 12:12 PM T=C4=B3l Coosemans <tijl at =
coosemans.org> wrote:
> > >
> > > On Thu, 7 Jan 2021 11:05:55 GMT Alex Richardson
> > > <arichardson at FreeBSD.org> wrote:
. . .
> > > NO_WERROR is also used by some ports [1] (which have to build =
against
> > > multiple version of FreeBSD) and this turns it into an error.  Can =
you
> > > remove this change or turn it into a warning maybe?  Changes to =
share/mk
> > > should always go through a ports exp-run IMHO.
> >
> > Ping Alex Richardson?
> >
> > Antoine (with hat: portmgr)
>=20
> Hi Antoine,
>=20
> I submitted https://reviews.freebsd.org/D28084 to change this error to =
a .info.
> However, T=C4=B3l said that there weren't many affected ports so this
> change should not be needed.
> I can commit this workaround, but if I do this just postpones the
> problem to when we want to remove the workaround (and might mean it
> will never be removed). Maybe those ports should just be built with a
> lower WARNS?

If one mistakenly leaves NO_WERROR in someplace like, say,
/etc/make.conf and so the errors occur during something
that uses make in a way that happens to do the check, such
as possibly in etcupdate's use of make, is the overall
behavior of the overall operation known to always avoid
doing anything nasty?

The same sort of question applies to a warning or such
but more is the same as before in that case and so
problems seem possibly less likely.

As far as I can tell, NO_WERROR becoming depreciated
had no transition period of notifications about
progressing past 12 to 13 or later. Existing procedures
may just suddenly stop working as intended where
NO_WERROR was in use for whatever reason.

(I had an example of missing a NO_WERROR removal and having
to recover from odd behavior that I expect was a consequence,
although I've not proven such. Having found and removed the
NO_WERROR, I've had no more such odd behaviors, which is at
least suggestive.)

=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9110AE5B-4BC0-4BF0-A33E-5E1C78224B9E>