On Mon, Aug 09 2021, Phillip Wood wrote: > Hi Carlo > > On 09/08/2021 02:38, Carlo Marcelo Arenas Belón wrote: >> similar to the recently added sparse task, it is nice to know as early >> as possible. >> add a dockerized build using fedora (that usually has the latest >> gcc) >> to be ahead of the curve and avoid older ISO C issues at the same time. > > If we want to be able to compile with -Wpedantic then it might be > better just to turn it on unconditionally in config.mak.dev. Then > developers will see any errors before they push and the ci builds will > all use it rather than having to run an extra job. I had a quick scan > of the mail archive threads starting at [1,2] and it's not clear to me > why -Wpedaintic was added as an optional extra. This is from wetware memory, so maybe it's wrong: But I recall that with DEVOPTS=pedantic we used to have a giant wall of warnings not too long ago (i.e. 1-3 years), and not just that referenced USE_PARENS_AROUND_GETTEXT_N issue. So yeah, I take and agree with your point that perhaps we should turn this on by default for DEVELOPER if that's not the case. On the other hand we can't combine that with USE_PARENS_AROUND_GETTEXT_N, and to the extent that we think DEVELOPER is useful, the entire point of having USE_PARENS_AROUND_GETTEXT_N seems to be to catch exactly that sort of in-development issue. So if we turn pedantic on in DEVOPTS by default, wouldn't it make sense to at least have a CI job where we test that we compile with USE_PARENS_AROUND_GETTEXT_N (which at that point would no be the default anymore). Or maybe the existing CI config matrix would already cover that, i.e. we've got some entry point to it that doesn't go through ci/lib.sh's DEVELOPER=1 that I've missed, if so nevermind the last two paragraphs (three, including this one).
