cmake topics & js/ci-disable-cmake-by-default (was: What's cooking in git.git (Dec 2022, #07; Mon, 26))

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Dec 26, 2022, 10:52 UTC
Message-ID: <221226.86y1quv1gw.gmgdl@evledraar.gmail.com>
In-Reply-To: <xmqqcz86n8bn.fsf@gitster.g>

I split up the previously merged to "next" ab/cmake-nix-and-ci and submitted the uncontroversial parts of it as:

	https://lore.kernel.org/git/patch-1.1-0fa41115261-20221219T102205Z-avarab@gmail.com
	https://lore.kernel.org/git/cover-0.2-00000000000-20221219T102813Z-avarab@gmail.com
	https://lore.kernel.org/git/cover-0.6-00000000000-20221219T183623Z-avarab@gmail.com

I think whatever happens with js/ci-disable-cmake-by-default that it makes sense to pick up & integrate those.

It's all narrow fixes for specific issues, none of which cover the area(s) that caused ab/cmake-nix-and-ci to be ejected from "next".

On Mon, Dec 26 2022, Junio C Hamano wrote:

Show 7 quoted lines

> * js/ci-disable-cmake-by-default (2022-12-20) 1 commit
>  - ci: only run win+VS build & tests in Git for Windows' fork
>
>  Stop running win+VS build by default.
>
>  Will merge to 'next'?
>  source: <pull.1445.git.1671461414191.gitgitgadget@gmail.com>

Per my feedback there, I still think it would make sense to at least split up the "should we build with MSVC?" from the "do we use cmake, and run the re-run tests we already ran with GCC with MSVC too?".

But I understand that Johannes disagreed with that, and didn't think testing MSVC in addition to GCC & Clang was valuable.

What I'd like clarification on if this moves forward is what the status of cmake in the tree is.

The reason I submitted ab/cmake-nix-and-ci was to make testing cmake+ctest on *nix trivial, so that if I and others made Makefile changes we could change & test the cmake recipe as well.

But now we won't even run that in CI, and "git-for-windows" will have ownership of it.

Does that mean that for such Makefile changes we should simply leave out the cmake changes, and rely on git-for-windows to "catch up" with its cmake contrib component?

Ultimately I don't mind such an arrangement, but I think that js/ci-disable-cmake-by-default brings us to a weird in-between state. Just removing it from the tree and having git-for-windows carry it would make sense.

So would IMO taking ab/cmake-nix-and-ci (or the restart of it above), i.e. to have cmake fixes accepted in git/git.

But now we're moving to a state where such patches aren't welcome, but we'll still carry inevitably bitrotting code in-tree, which we're intentionally not testing anymore until it's merged to git-for-windows?

Thanks.