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

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

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.