Hi, On Tue, 6 Dec 2022, Ævar Arnfjörð Bjarmason wrote: > On Tue, Dec 06 2022, Phillip Wood wrote: > > > On 06/12/2022 03:52, Junio C Hamano wrote: > >> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > >> > >>> Just to add my own digression: I asked in some past thread (which > >>> I'm too lazy to dig up) why it was the cmake file couldn't just > >>> dispatch to "make" for most things. > > > > Because make is not installed by default on Windows. Our CI job uses > > msbuild (whatever that is) and when I was playing with Visual Studio > > last week it was using ninja. > > > >>> I.e. it needs to at some level be aware of what it's building for the > >>> IDE integration, but for say making a "grep.o" there's no reason it > >>> couldn't be running: > >>> > >>> make grep.o > >>> > >>> Instead of: > >>> > >>> cc <args> -o grep grep.c [...] > >>> > >>> which requires duplicating much of the Makefile logic (possibly with > >>> some Makefile shim to not consider any dependencies in that case). > >> That leads to a question at the other extreme. Why does any logic > >> in CMakeLists.txt even have to exist at all? Whenever it is asked > >> to make foo, it can be running "make foo" instead of having its own > >> logic at all. ;-) > > > > Yes, if make was available then we wouldn't need to use CMake. > > I think Junio and I are talking about something slightly different. Yes > "make" isn't available by default. Getting it requires installing a > larger SDK. > > But if you look at the history of contrib/vscode/README.md in our tree > you'll see that we used to support this "Visual Studio Solution" for > years via GNU make, it probably still works. It probably doesn't. Last time I had to use it, during the embargoed v2.37.1 release process, it didn't. I had to add plenty of patches to make it work again: https://github.com/git-for-windows/git/compare/323a69709944%5E...323a69709944%5E2 > The change in 4c2c38e800f (ci: modification of main.yml to use cmake for > vs-build job, 2020-06-26) shows when the CI was switched over to using > cmake instead. > > The code to support that is still in-tree as the "vcxproj" target in > "config.mak.uname", which calls out to the ~1k lines of Perl code in > contrib/buildsystems/Generators/*. At some stage we can probably get rid of the `vcxproj` code. Before that, we can even get rid of the `vcproj` code that is bit-rotting in `contrib/buildsystems/`. But there seems no harm, and less maintenance burden, in keeping the `vcxproj`/`vcproj` parts where they are, as they are. Taking a step back, I see that we got far away from the topic that started this thread. So here's my take on `ab/cmake-nix-and-ci`: While that patch series' intention is apparently to make it easier to diagnose and fix CI problems, I only see that it adds new problems. It won't make it possible to diagnose most win+VS problems because they don't reproduce on Linux. But the patches already did introduce Windows-specific problems merely by trying to get the Linux side of CMake to work. And trying to keep CMake working both on Linux and on Windows would cause many more problems in the future. And we do not even need CMake support for Linux, `make` works well there already. It would increase the maintenance burden unnecessarily. I am therefore suggesting to drop `cmake-nix-and-ci` entirely. To address the concern about broken CI runs, I hoped that monitoring them and helping contributors by suggesting fixups was working well enough. It used to be okay for patches to be contributed that caused CI to fail, we simply worked together to fix CI, as a team, and that was that. We didn't "blame" the contributors, or anything, when CI runs failed because of their patches. After all, possible causes of CI failures include that patches might be applied on top of other commits than intended, or that patch series interact in unfortunate ways. Junio, maybe you could clarify your take on this? As project lead, it is your decision to define how Git uses Continuous Builds, and how the project handles failed CI runs. Ciao, Johannes
