Re: [PATCH 2/3] ci: avoid bare "gcc" for osx-gcc job

From: Jeff King <peff@peff.net>
Date: May 10, 2024, 22:02 UTC
Message-ID: <20240510220228.GA1962678@coredump.intra.peff.net>
In-Reply-To: <CAO_smVhE25ZQqc1f_fx9oPX-kH8SHxwEc=mqOAi-xQ91+pF1CA@mail.gmail.com>

On Fri, May 10, 2024 at 01:32:15PM -0700, Kyle Lippincott wrote:

Show 15 quoted lines

> On Thu, May 9, 2024 at 9:24 AM Jeff King <peff@peff.net> wrote:
> >
> > On macOS, a bare "gcc" (without a version) will invoke a wrapper for
> > clang, not actual gcc. Even when gcc is installed via homebrew, that
> > only provides version-specific links in /usr/local/bin (like "gcc-13"),
> > and never a version-agnostic "gcc" wrapper.
> >
> > As far as I can tell, this has been the case for a long time, and this
> > osx-gcc job has largely been doing nothing.
> 
> If it's been doing nothing (which I interpreted as "it's doing the
> same thing as osx-clang"), and we've not noticed any issues with that,
> do we need the job at all? Should we just rely on clang and not test
> with gcc on macOS, since it's not a compiler that's provided by the
> platform anymore?

Your interpretation is correct; it was just doing the same thing as osx-clang. As I said earlier, I'd be fine with just dropping it. It's possible that there is value in testing there with gcc (that we've been missing out on), but to know that we'd have to understand the original reasons it was added.

Looks like it came from 889cacb689 (ci: configure GitHub Actions for CI/PR, 2020-04-11), but that was just porting from the Azure pipelines config. That system got its osx_gcc job from 27be78173d (Add a build definition for Azure DevOps, 2019-01-29), but that in turn was just porting the Travis config. The Travis job came from 522354d70f (Add Travis CI support, 2015-11-27), and there's no specific rationale given. But it used a build matrix of (os, compiler), so we got all four of {linux,osx}-{gcc,clang}. So it mostly seems like "more is better" and that was the easiest way to define it.

I do think there's value in testing with both clang and gcc in general[1]. And there is _some_ code which is compiled only on macos and not elsewhere. So this would be our only chance for gcc to see it. But it seems like a pretty small return for an entire parallel job. Especially as I do not think it has uncovered anything interesting in the past (even when it was working).

-Peff

[1] Another quirk is that we run the whole test suite for both
    compilers, which is probably overkill. The main value in comparing
    gcc vs clang is that we don't use any constructs that the compiler
    complains about. It's _possible_ for there to be a construct that
    the compiler does not notice but which causes a runtime difference
    (say, undefined behavior which happens to work out on one compiler),
    but I think we're again hitting diminishing returns.