Hi Konst, On Sun, 3 May 2020, Konstantin Tokarev wrote: > > > 03.05.2020, 20:21, "Junio C Hamano" : > > Sibi Siddharthan writes: > > > >>>  As you say, an extra instruction in INSTALL file to tell users to > >>>  copy from contrib/cmake may workable, though it is unsatisfactory. > >>>  But the other one will not simply work. If we need to have a new > >>>  file with string "CMake" in its name at the top-level *anyway*, we > >>>  should have the real thing to reduce one step from those who want to > >>>  use it. Those who do not want to see "CMake" at the toplevel are > >>>  already harmed either way, if is a dummy or if it is the real thing. > >> > >>  In your opinion, what would be the best way to communicate with users, there is > >>  an optional CMake build system for git? > > > > You do not want to hear my opinion, as my priorities would be > > different from yours ;-) > > > > Given that we all agreed that the only reason we contemplate use of > > CMake in our project is strictly to help Windows build, i.e. due to > > the same reason why we have contrib/buildsystems/, it is not one of > > my goals to communicate with general users about optional CMake > > support in the first place. It has lower priority than keeping the > > project tree and the project history less cluttered. > > > > So my first preference would be an instruction somewhere in install > > or readme that tells those who want to build for windows to copy > > from (or perhaps update cmake to offer the "-f" option and tell it > > to read from) contrib/cmake/CMakeLists.txt to the toplevel before > > doing anything [*1*]. > > FWIW, CMakeLists.txt doesn't have to be in the root of source tree in > order to work. It can perfectly work from contrib/cmake after necessary > changes in relative paths. Would you have an example handy, or a link to an article describing this? Ciao, Johannes