On Mon, Dec 05 2022, Jeff King wrote: > On Mon, Dec 05, 2022 at 06:34:09PM -0500, Taylor Blau wrote: > >> 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 think part of the reason cmake rose in importance via CI is that it's > the de facto way to build for vscode. Before that CI job switched to > cmake, there was some other alternate build system (vcxproj). > > So two things I'd consider here: > > - how important is it for us to do the vscode build as part of regular > CI (as opposed to folks who are interested in it running it > themselves). Dscho gave some real data in the thread I linked to > earlier (which indicates that yes, it helps, but not that often). > > - what's the status of cmake versus vcxproj? My impression (though I > admit based on my half-paying-attention-to of the topic) is that > cmake should replace vcxproj, and nobody would ever want to work on I think the intent was to deprecate vcxproj, but I'm not sure, and I wonder if the "cmake" is the proposed path forward why we still have it in-tree anymore. > vcxproj anymore. But if that's not right, then does vcxproj cause > headaches for non-Windows devs less often? I don't really remember > dealing with it much, but I may have just been lucky. It was less painful for non-Windows folks, but I understand the cmake integration was also much nicer for VS. I.e. it's picked up by the IDE in a way that the "make" shim wasn't. > [...] > That seems like going in the opposite direction from what you're saying > above: doubling down that if cmake is broken by a change, it is the > responsibility of the dev who made the change to find and fix it. > > I do like that Ævar is trying to make it easier to run cmake from Linux > in order to find that without using CI. But that does seem orthogonal to > me to the notion of "who is responsible for finding and fixing cmake > problems". To me, that decision is really rooted in "is cmake something > the Git project supports, or is it a side-thing that some folks > volunteer to keep working?". I agree with that... >> 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. > > I don't mind having it in-tree if I can ignore it (assuming the project > attitude is the "it's a side thing" from above). It's the CI failures > that make it hard to ignore. ...but on this thread-at-large, I'd much rather see us focus on just reviewing the patches I have here than raising the burden of proof to whether we should get rid of it entirely. If we make the CI failures "soft" failures or move it out-of-tree entirely it would still be useful to be able to run the cmake recipe on *nix.
