From: Junio C Hamano <gitster@pobox.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: cmake topics & js/ci-disable-cmake-by-default
Date: Tue, 27 Dec 2022 13:26:15 +0900 [thread overview]
Message-ID: <xmqqilhxv5eg.fsf@gitster.g> (raw)
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.
>> * 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?
> 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.
next prev parent reply other threads:[~2022-12-27 4:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-26 3:38 What's cooking in git.git (Dec 2022, #07; Mon, 26) Junio C Hamano
2022-12-26 10:52 ` cmake topics & js/ci-disable-cmake-by-default (was: What's cooking in git.git (Dec 2022, #07; Mon, 26)) Ævar Arnfjörð Bjarmason
2022-12-27 4:26 ` Junio C Hamano [this message]
2022-12-27 13:59 ` cmake topics & js/ci-disable-cmake-by-default Ævar Arnfjörð Bjarmason
2022-12-27 23:06 ` Junio C Hamano
2022-12-28 8:36 ` built-in-submodule & in-flight dependencies (was: What's cooking in git.git (Dec 2022, #07; Mon, 26)) Ævar Arnfjörð Bjarmason
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqilhxv5eg.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).