Re: cmake topics & js/ci-disable-cmake-by-default

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 27, 2022, 04:26 UTC
Message-ID: <xmqqilhxv5eg.fsf@gitster.g>
In-Reply-To: <221226.86y1quv1gw.gmgdl@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

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

Not gathering any interest by folks who will be affected is different from being uncontroversial, though. It may not have seen any controversy so far, but once it reappears in my tree and sufficiently advances to cause trouble to other people, it would.

In other words, I am saving time and energy of people by waiting for positive support on these changes.

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

I do not think so at all, at least judging by what little has been said so far on the list. Comments on two among these three are negative ones, and the other one had no traction.

Show 11 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?".

Do you mean that in our primary CI jobs, you would, using Makefile, want to keep building the win+VS artifacts with MSVC and running the tests, even though Windows folks want to drive the same build process via CMake, and their release binaries will come from the latter?

I am not sure which extra corners, which matter to us, are covered by doing so. What's the upside?

Show 6 quoted lines

> 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?

That is the natural conclusion of what has been said on the list so far. We do not even "rely on"---it is up to them who chose to use CMake to keep it up to date or lag behind. Among those who have made significant contributions and works outside Windows, we found nobody whowants to touch CMake.

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

That's fine by me personally, but somebody has to help coordinating such a move between two projects.