On Fri, Nov 19 2021, Johannes Schindelin wrote: > On Fri, 19 Nov 2021, Ævar Arnfjörð Bjarmason wrote: > >> I think getting it working on non-Windows if we're going to keep it >> (which looks to be the case) would be very useful. > > The idea to extend the CMake to more than just Windows is contrary to what > Junio said in > https://lore.kernel.org/git/xmqq1rmcm6md.fsf@xxxxxxxxxxxxxxxxxxxxxx/: > > Let's not worry about cross-platform and instead stick to Windows > and nothing else for now to expedite the process. As long as it > is advertised as such, nobody would complain that it does not work > on Linux or macOS. That's quoted in the <211119.86ee7c4n8r.gmgdl@xxxxxxxxxxxxxxxxxxx> you're replying to. No need to repeat it. > If that is not enough to tone down opposing opinions (the opinion of the > Git maintainer is more important, after all, it's his maintenance burden > so he gets to decide), you can also look at this statement from > https://lore.kernel.org/git/xmqq8sikblv2.fsf@xxxxxxxxxxxxxxxxxxxxxx/: > > I already said that I feel that engineering burden to divert > resources for CMake support would be unacceptably high. There's some back & forth in that thread, I do think a fair summary of it is that the proponents of CMakeLists.txt, including yourself, assured reviewers that having the cmake component wouldn't place a maintenance burden on anyone not using it. Including yourself at: https://lore.kernel.org/git/nycvar.QRO.7.76.6.2004251354390.18039@xxxxxxxxxxxxxxxxx/: When it comes to new Makefile knobs, I do agree that it would place an unacceptable burden on contributors if we expected them to add the same knob to CMakeLists.txt. But we already don't do that for our autoconf support, so why would we expect it for CMake? When it comes to adding new, and/or removing, files, I fail to see the problem. It is dead easy to keep the Makefile and CMakeLists.txt in sync when it comes to lists of files. The "that it" here refers to "slow our existing developers down by forcing them to become familiar with CMake", which you quote below. > The only reason we have CMake in addition to the Makefile (and the > autoconf-based) setup is that CMake makes it possible to build Git on > Windows in the development environment with which the majority of the > developers on Windows are familiar: Visual Studio. > > If it weren't for those developers, for who it would be a ridiculous > suggestion to "just go download GNU make", we would not have the CMake > based build at all. I'm happy it works for those developers, and don't mind at all that they're choosing to run a propriterary stack while developing a free software project, I'd just prefer not to be forced to do that because our CI has a hard dependency on it. We can argue about the trade-offs here, but I think it's clearly hyperbole to say that would be a ridiculous suggestion when it was the status quo until 2020. I'm specifically pointing out that the issue with the hard dependency of CI on this "contrib" component. I'd think of all people you'd be in vehement agreement with me on that point, after all our back & forth on the contrib/scalar topic, and that things "contrib" must be decoupled and "optional" in a way that this cmake integration clearly isn't. > And I am still agreeing with what Junio further said in the second mail I > linked above: > > [...] it is unclear why it would be beneficial to slow our > existing developers down by forcing them to become familiar with > CMake. > > So now we are discussing to extend the CMake build to allow Linux and > macOS developers to use it, to, for little to no benefit. We are very much > in the situation where we are slowed down by discussing something as > non-essential as extending our CMake support beyond Windows, while patches > that are provably much more beneficial to a lot more people are left > under-reviewed. > > Even worse: reviewers who _could_ provide high-quality reviews for those > patches (which takes a lot of time and diligence), but are as much pressed > for time as I am and therefore have to choose wisely how to spend their > time, are _actively_ distracted from spending their time more wisely. > > Can't we please focus on more relevant things again? Pretty please? We have out-of-tree patches to make this thing work outside of Windows authored by Phillip, and it sonuds like Đoàn would find it useful too. As for myself I really don't care to interact with this cmake component at all, but if we're not going to drop the CI hard dependency on it I'd find being able to test it on a free OS locally to be vastly preferrable. In any case, I'm not submitting patches in that direction. But I don't see a reason to discourage other people from collaborating on topics they may find useful, as you're doing here.
