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

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

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:

> * 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.