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

From: Taylor Blau <me@ttaylorr.com>
Date: Dec 6, 2022, 00:35 UTC
Message-ID: <Y46OTYvVjdKJfQai@nand.local>
In-Reply-To: <221206.864ju9e6fa.gmgdl@evledraar.gmail.com>

On Tue, Dec 06, 2022 at 12:46:50AM +0100, Ævar Arnfjörð Bjarmason wrote:

Show 23 quoted lines

> I'm just trying to point out that that wouldn't be such a big deal if
> the cmake parts were being actively maintained.
>
> >   - 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?
>
> Yes, some things will just work. E.g. it regex-parses out the Makefile
> to pick up the list of built-ins, so when we add a new one we'd usually
> not need to patch the cmake bits. Although that regex parsing is its own
> problem for some Makefile changes.
>
> To be fair the cases where we've needed to keep it in lockstep since it
> was added aren't that many. If you skim this and look for commits that
> alter both (or cmake quickly after the Makefile) you can spot them:
>
>       git log --oneline --no-merges --full-diff --stat 1c966423263..origin/master -- contrib/buildsystems/CMakeLists.txt -- Makefile

I think that this is exactly the problem I'm trying to chime in about. We know that regular contributors can propose sensible changes to the Makefile.

But integrating CMake into our tree in such a way that forces all Git developers to *also* be familiar with CMake is too large of a change to hoist onto the Git community, I think.

Show 18 quoted lines

> > 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.
>
> I wouldn't mind either to see it gone, but when that was last discussed
> some people chimed in to say that it really made things easier on
> Windows, and I'm inclined to believe them.
>
> So I'm not trying to take their toys away, just changing it so that if
> you run into these cmake issues it'll be trivial to debug them, as
> you'll be able to test & run it outside of Windows.

OK. Personally, I wouldn't be sad to see it gone, either. I wonder: is there a way to keep it in our tree such that CMake breakage isn't everybody's problem (like Peff originally suggested when we were discussing this in the first place)?

If so, I would vastly prefer that to the state that we have now. If not, I think moving it out of the tree is a sensible step, and one that I would advocate for.

Thanks, Taylor