Jeremie Courreges-Anglas wrote (2023-01-08 23:49 CET): > On Sun, Jan 08 2023, Daniel Dickman <didick...@gmail.com> wrote: > >> On Jan 8, 2023, at 11:59 AM, Omar Polo <o...@omarpolo.com> wrote: > >> > >> On 2023/01/08 16:25:16 +0100, Jérémie Courrèges-Anglas <j...@wxcvbn.org> > >> wrote: > >>> https://wxcvbn.org/~jca/build-failures/amd64-clang/2023-01-03/devel/fnc.txt > >> > >> fails building the bundled sqlite3 copy because of: > >> > >> : lib/sqlite3.c:57910:7: error: variable 'nUri' set but not used > >> [-Werror,-Wunused-but-set-variable] > >> : int nUri = 0; /* Number of URI parameters */ > >> : ^ > >> : 1 error generated. > >> > >> don't have the newer clang here yet but this should fix the build. > >> > >> ok? > > > > > > Instead of removing error, would turning off the specific check work > > instead? ie. Add > > > > -Wno-unused-but-set-variable > > I'm not sure how you are asking: op@ the OP, sdk@ (maintainer) or me, > but I'll reply anyway. As for me, I'm perfectly happy with > dropping -Werror in this port, and more generally in any port. My > opinion is that -Werror in ports mostly written on other operating > systems wastes porters time. > > If a maintainer wants to keep -Werror, then he gets to keep the pieces > when the port breaks. For devel/fnc, Stefan is the maintainer, so he > gets the last word. > > But if a port has no maintainer, and we strive to keep on using -Werror, > who's going to fix the port the next time it breaks? Should we add > a MAINTAINER-Werror variable? > > Don't get me wrong, compiler warnings are usually useful, and -Werror > *sometimes* has value. But the ports tree is a deep jungle with lots of > weird animals in it.
@Daniel: I find -Werror useful at development time. For a release build it's more of a burden because it sometimes breaks builds down the line and rarely for a good reason (as seen here). Most warnings should get fixed upstream. I don't see us carrying patches for "unused-*" or even deprecated-*. Therefore -Werror should be dropped. I ok'd the diff already. Best Regards, Stefan
