Hi Sibi, On 25/04/2020 05:09, Sibi Siddharthan wrote: > On Sat, Apr 25, 2020 at 3:13 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Sibi Siddharthan <sibisiddharthan.github@xxxxxxxxx> writes: >> >>> The goal would be to maintain a CMake build for Git keeping it in sync >>> with the Makefile. >>> The Makefile is not going to be replaced at all. The CMake script for >>> now only supports Linux and Windows. >>> It does not support BSD, Solaris and others, whereas the Makefile does >>> support them. >> So you are doing (1). I already said that I feel that engineering >> burden to divert resources for CMake support would be unacceptably >> high. >> >> Whenever any of our developers need to add source files, Makefile >> configuration knobs that people can add to config.mak, etc., you are >> forcing them to figure out where in the CMakefile to add them or >> devise ways to allow builders who do not use config.mak (because >> they use CMake) to do similar tweaks. >> > Adding source files to the CMakefile is going to just as long as > adding it to the Makefile, > anyone can figure this out and this is not going to take much time at all. While figuring these things out isn't /hard/ it can be tedious and time consuming for those who are not familiar with the particular tool set (as evidenced, in my mind, by the poor dev support for Git for Windows because of the need to understand two operating systems and their awkward interactions) - those that are familiar and understand the/their whole tool set are usually the x10 folks. > > As for the configuration knobs I agree that adding the same to CMake > is going to a bit longer. > But anyone who is hacking Git is going to do it with the Makefile or > (if accepted)CMake script, but not both while hacking. > So they will continue to make progress with the system they feel comfortable in. > They will only run into an issue when they try for a PR. Currently the > CMake script is only used for generating the visual studio solution. > We can add a (continue-on-error) to vs-build job to make this process > less of a hindrance. > If people take the time to hack Git, figuring out how to do the > configuration knobs in the CMake script is not going to that much take > time > compared to the time they spend making Git better. > > >> Any patch that is acceptable to the current project would become >> unacceptable because they lack updates to CMake part, but I suspect >> we do not have enough people who are so much devoted to give a good >> review if updates to CMake part are added. And it is unclear why it >> would be beneficial to slow our existing developers down by forcing >> them to become familiar with CMake. >> >> So..., I am not just "still not convinced", but I am even more >> convinced that we do not want this series, after thinking about it >> longer. >> >> Thanks. >> Is there a middle way, given that IIUC there is most benefit on the Windows side, that on the git.git side the Makefile could contain a suitable comment directing those interested in CMake to the relevant part of Git-for-Windows. Is there a part that could hold, and track, the matching changes to the primary Makefile? Are there tools that track and compare CMake and Make variants, or at least indicate any divergences to help separately maintaining the CMake series? > Thank You, > Sibi Siddharthan -- Philip
