Re: [PATCH/RFC 3/3] ci: run a pedantic build as part of the GitHub workflow
- From
Carlo Arenas <carenas@gmail.com>
- Date
- Aug 31, 2021, 20:28 UTC
- Message-ID
- <CAPUEspj43=z8nSdh8UAiqZ+UR8UAZkSsQr1WviGtasQ7d-fHTQ@mail.gmail.com>
- In-Reply-To
- <87zgszxirn.fsf@evledraar.gmail.com>
On Mon, Aug 30, 2021 at 4:40 AM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
Show 19 quoted lines
> On Mon, Aug 09 2021, Phillip Wood wrote: > > 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.
when gcc (and clang) moved to target C99 by default (after version 5) then that wall of errors went away. Indeed git can build cleanly in a strict C99 compiler and until reftable was able to build even with gcc 2.95.3
the nostalgic can get it back with `CC=gcc -std=gnu89`, and indeed I was considering this might be a good alternative to the defunct gcc-4.8 job, where the weather balloons breaking with strict C89 compatibility could be explicitly coded.
> 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 not be the default > anymore).
agree, and indeed was thinking it might be worth combining this job with the SANITIZE one for efficiency.
Carlo