On Mon, Aug 03, 2020 at 10:35:40PM -0700, Junio C Hamano wrote: > * ss/cmake-build (2020-06-26) 8 commits > (merged to 'next' on 2020-08-03 at a0d70165c1) > + ci: modification of main.yml to use cmake for vs-build job > + cmake: support for building git on windows with msvc and clang. > + cmake: support for building git on windows with mingw > + cmake: support for testing git when building out of the source tree > + cmake: support for testing git with ctest > + cmake: installation support for git > + cmake: generate the shell/perl/python scripts and templates, translations > + Introduce CMake support for configuring Git > > Originally merged to 'next' on 2020-08-01 > > CMake support to build with MSVC for Windows bypassing the Makefile. > > Will merge to 'master'. > cf. https://github.com/git/git/runs/892824895 I ran into issues with this, as I have several in-progress topics (not yet sent to the list) that touch our Makefile, and they needed updates to the cmake file (because it reproduces a lot of the lists and logic from the Makefile). The original philosophy behind putting it in contrib is that most people wouldn't have to care, and folks interested in cmake would be responsible for keeping it up to date. But the top patch makes it hard to ignore, because the vs-build CI job will fail. I'm not sure of the right path forward. I was definitely unenthused to be dealing with cmake, and the problem came up as soon as the series hit next. On the other hand, it was only 2 out of my 47 topics that triggered problems. I'd guess that's representative of how often this will come up. And the vsbuild tests have to use _something_, so we may not be immune to this problem regardless of the solution (though I never had to touch the vcxproj files before). Part of me wants to just ignore vsbuild test results completely, but it has provided value in the past (for actual code changes with portability issues). So I dunno. I'm not really asking for or recommending any specific action, but just raising the data point. -Peff
