On Mon, Dec 05 2022, Taylor Blau wrote: > 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@xxxxxxxxxxxxxxxxxxxxxxx/ >> > >> > 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. 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 > 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. Now, I'm about to send out a v6 of it, which should address the last remaining Windows/VS issues. I'm not testing directly there, as I don't have such an installation, so it's possible I'm wrong. Maybe it works in CI, but still breaks for some reason when driven from VS. But I think if we can't get anyone who's running Windows+VS to be interested enough in this to test it the better thing is to just take this series. Maybe it breaks some subtle aspect of the VS integration, but then that'll be easier to fix on top than recovering from a "git rm" of it.
