git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH 2/2] ci: let pedantic job compile with -Og
Date: Thu, 6 Jun 2024 10:25:47 +0200	[thread overview]
Message-ID: <ZmFyi1fQ14tVy7Xg@tanuki> (raw)
In-Reply-To: <20240606080552.GA658959@coredump.intra.peff.net>

[-- Attachment #1: Type: text/plain, Size: 3284 bytes --]

On Thu, Jun 06, 2024 at 04:05:52AM -0400, Jeff King wrote:
> On Thu, Jun 06, 2024 at 09:41:56AM +0200, Patrick Steinhardt wrote:
> > I kind of wonder whether we should revamp this pedantic job in the first
> > place. The consequence of that job is that our codebase needs to be
> > compile cleanly with `-Wpedantic`. So if that is a requirement anyway,
> > why don't we run all jobs with `DEVOPTS=pedantic` and just drop this job
> > altogether? This may surface some additional warnings on platforms where
> > we currently don't set that, but is that a bad thing?
> 
> Yeah, if we always compile cleanly with pedantic, then I don't see why
> it wouldn't just be the default for DEVELOPER=1. The point of that flag
> is to be as picky as possible so that we catch things early. If some
> platform can't handle it (let's imagine Windows or something), then I
> think we should be explicitly _disabling_ pedantic there.
> 
> > The only downside I can think of is that we stop compiling on Fedora,
> > which may have a more up-to-date GCC version than Ubuntu. But if the
> > goal of this job was to _really_ get an up-to-date compiler toolchain,
> > then we should rather pick a rolling release distro like Arch. Otherwise
> > I find this to be of dubious benefit.
> 
> There may be some value in general in compiling on multiple distros, as
> a sort of "unknown unknowns" thing. We don't know what we might turn up,
> but exposing ourselves to more variables may lead to catching failures
> before users see them.
> 
> I don't know if Fedora was specifically chosen for recent gcc there, or
> if it was simply for variety.

True enough. But even so, I think the better solution here would be to
drop one of the Ubuntu-based jobs and then convert the Fedora one into a
fully-fledged job that also runs tests.

That's something for a later iteration, though.

> Once again, these overlapping variables within various jobs make it hard
> to reason about (but I don't propose normalizing all of them; that would
> increase the amount of CPU work by a lot; I am just grumbling).

No arguing there, it certainly is hard to discover overall. I don't
really think there's a way around this if we want to have different
combinations while not running a full matrix of jobs, because the
combinations are always going to be arbitrary.

> But yeah, between Arch and Fedora, I don't have an opinion. Doing both
> might even be valuable, if we are shoving random variations into random
> jobs. ;)

True.

> > If we merge it into the other jobs, then I'd just pick any random job
> > that uses "ubuntu:latest" like "linux-gcc-default" to compile with
> > `-Og`.
> 
> That would be OK with me. I also think it would be OK to do nothing for
> now. We saw one case where "-Og" found a warning that "-O2" didn't. We
> could wait to see if it happens twice before acting. I dunno.

I don't think it hurts to have a job with `-Og`, and if it detects some
corner cases that we otherwise don't I think there's a real benefit. In
the best case, I'd want to give everyone the tools to avoid sending
patch series to the mailing list which are broken and where that could
have been detected earlier. In the end, it saves everybody's time.

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2024-06-06  8:25 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-06  6:30 [PATCH 0/2] ci: detect more warnings via `-Og` Patrick Steinhardt
2024-06-06  6:30 ` [PATCH 1/2] ci: fix check for Ubuntu 20.04 Patrick Steinhardt
2024-06-06  6:53   ` Jeff King
2024-06-06  7:44     ` Patrick Steinhardt
2024-06-06  6:30 ` [PATCH 2/2] ci: let pedantic job compile with -Og Patrick Steinhardt
2024-06-06  6:52   ` Jeff King
2024-06-06  7:41     ` Patrick Steinhardt
2024-06-06  8:05       ` Jeff King
2024-06-06  8:25         ` Patrick Steinhardt [this message]
2024-06-06  9:31         ` [PATCH v2 0/2] ci: detect more warnings via `-Og` Patrick Steinhardt
2024-06-06  9:31           ` [PATCH v2 1/2] ci: fix check for Ubuntu 20.04 Patrick Steinhardt
2024-06-06  9:31           ` [PATCH v2 2/2] ci: compile "linux-gcc-default" job with -Og Patrick Steinhardt
2024-06-06 15:32             ` Justin Tobler
2024-06-06 17:02             ` Junio C Hamano
2024-06-07  5:28               ` Patrick Steinhardt
2024-06-07 18:45                 ` Junio C Hamano
2024-06-08  8:49                   ` Jeff King
2024-06-07 18:48             ` Junio C Hamano
2024-06-07 20:35               ` Junio C Hamano
2024-06-07  6:46         ` [PATCH v3 0/4] ci: detect more warnings via `-Og` Patrick Steinhardt
2024-06-07  6:46           ` [PATCH v3 1/4] ci: fix check for Ubuntu 20.04 Patrick Steinhardt
2024-06-07  6:46           ` [PATCH v3 2/4] Makefile: add ability to append to CFLAGS and LDFLAGS Patrick Steinhardt
2024-06-08  8:55             ` Jeff King
2024-06-08 19:01               ` Junio C Hamano
2024-06-10  7:01                 ` Patrick Steinhardt
2024-06-07  6:46           ` [PATCH v3 3/4] ci: compile code with V=1 Patrick Steinhardt
2024-06-07  6:46           ` [PATCH v3 4/4] ci: compile "linux-gcc-default" job with -Og Patrick Steinhardt
2024-06-07 20:47           ` [PATCH v3 0/4] ci: detect more warnings via `-Og` Junio C Hamano
2024-06-08  9:28             ` Jeff King
2024-06-08 23:12               ` Junio C Hamano
2024-06-10  6:25                 ` Patrick Steinhardt
2024-06-06 16:32     ` [PATCH 2/2] ci: let pedantic job compile with -Og Junio C Hamano
2024-06-07  5:10       ` Patrick Steinhardt
2024-06-07 18:42         ` Junio C Hamano
2024-06-10  6:38 ` [PATCH v4 0/2] ci: detect more warnings via `-Og` Patrick Steinhardt
2024-06-10  6:38   ` [PATCH v4 1/2] Makefile: add ability to append to CFLAGS and LDFLAGS Patrick Steinhardt
2024-06-10  6:38   ` [PATCH v4 2/2] ci: compile "linux-gcc-default" job with -Og Patrick Steinhardt
2024-06-10 16:06     ` Junio C Hamano
2024-06-10 18:36       ` [PATCH 1/2] DONTAPPLY: -Og fallout workaround Junio C Hamano
2024-06-10 20:05         ` Junio C Hamano
2024-06-11 12:09           ` Patrick Steinhardt
2024-06-11 17:30             ` Junio C Hamano
2024-06-12  4:42               ` Patrick Steinhardt
2024-06-12  4:45                 ` Patrick Steinhardt
2024-06-10 18:36       ` [PATCH 2/2] DONTAPPLY: -Os " Junio C Hamano
2024-06-12 22:11       ` [PATCH v4 2/2] ci: compile "linux-gcc-default" job with -Og Junio C Hamano
2024-06-13 10:15         ` Jeff King
2024-06-13 15:47           ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZmFyi1fQ14tVy7Xg@tanuki \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).