Re: [PATCH] test-lib.sh: discover "git" in subdirs of "contrib/buildsystems/out"

[Taylor Blau <me@ttaylorr.com>]

On Sat, Dec 03, 2022 at 02:41:04AM +0100, Ævar Arnfjörð Bjarmason wrote:
> > I have similar feelings to you here. Back when cmake support was
> > introduced, I explicitly wanted it to be something for people who cared
> > about it, but that wouldn't bother people who didn't use it:
> >
> >   https://lore.kernel.org/git/20200427200852.GC1728884@coredump.intra.peff.net/
> >
> > I stand by that sentiment, but it seems to have crept up as a required
> > thing to deal with, and that is mostly because of CI. Using cmake in CI
> > is good for telling developers when a change they make has broken cmake.
> > But it also makes cmake their problem, and not the folks interested in
> > cmake.
>
> That's a bit of a pain, but I don't think the main problem is its
> integration with CI. It's that there doesn't really seem to be an
> interest in its active maintenance & review from its supposed main
> target audience.
>
> Case in point this "ab/cmake-nix-and-ci" topic: It's been queued for
> around 2 months now.

I think CI *is* the problem here. The CMake bits are basically a black
box to me (and I suspect a large number of other contributors, too). But
when it breaks, the only reason we as a project end up noticing it is
because it has fallout in CI.

I would not be sad to make CI failures that are derived from CMake
"soft" failures in the sense that they don't make the build red. But I
think it's masking over a couple of bigger issues:

  - Why do we "support" two build systems in CI if one is supposed to
    only be here for those that care about it? IOW, even if we say that
    CMake support is nominally an opt-in thing, in reality it isn't
    because of the dependency via CI.

  - Why do we only *notice* these failures in CI? I found during my time
    as interim-maintainer the task of tracking down CI failures to quite
    frustrating. It is often quite difficult to reproduce CI failures
    locally (especially with exotic build and test configurations[^1]).

It would be nice to be able to more easily see these failures locally
before they hit CI. E.g., is it possible that I would work on a feature
which somehow breaks the CMake build, and fail to notice it if I use
"make" locally?

Personally, I would not be sad to see CMake removed from the tree
entirely because it has not seen enough maintenance and seems to be
quite a headache.

Thanks,
Taylor

[^1]: Not to mention non-Linux failures, though I think that is sort of
  par for the course if you're not using one of those platforms
  yourself.