On 2020-09-18 09:21:45-0700, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Đoàn Trần Công Danh <congdanhqx@xxxxxxxxx> writes: > > > Actually, in CMake land, people usually do this instead: > > > > mkdir build > > cmake [-Ggenerator] .. > > <make/ninja/msbuild> > > I presume you "cd build" between steps 1 & 2? Opps, yes, there is a "cd build" there, and it should be: cmake [-G<generator>] .. <generator> is the target build system, default to "Unix Makefiles" in *nix land. > I take the "people usually do" is the best current practice? I would say it's the best practice. It's recommended in cmake official guide (although, they don't write the word "best practice") [1] It is recommended to build in a separate directory to the source because that keeps the source directory pristine, allows for building a single source with multiple toolchains, and allows easy clearing of build artifacts by simply deleting the build directory. > > > Then, when they want to run something equivalent with make distclean, > > they run: > > > > cd .. > > rm -rf build > > > > instead. > > > > The change that Dscho suggested was meant for those people that run > > CMake in same directory of source dir, which is mostly discouraged > > in CMake land. > > > > In additional, CMake's default Generator in *nix is Unix Makefiles, > > which will clash with our Makefile, and totally unsupported. > > I recall that our CMakeLists file asks the top-level Makefile about > basic things so that we do not have to duplicate "list of files" > etc. in places, so I can understand that it would lead to a > disaster to do "cmake -Ggenerator" at the top-level. Yes, and in some first iteration, the proposal didn't check for builddir != sourcedir when -G"Unix Makefiles", which was corrected later. I haven't checked, but I could imagine that "cmake -Gninja" at top-level sourcedir should work without problems, though. > > I think the original CMake proposal didn't touch .gitignore because > > they run in a separated build-dir. > > If so, not only my "do we need a matching change to CMakeLists to > teach how to clean crufts?" becomes unnecessary, but the original > patch that started this thread to touch .gitignore at the top level, > does, too. > > I wonder what led Dscho not to follow the "create a 'build' dir and > do things there" practice. Judging from the fact that the "because > they run in a separate build directory" assumption did not hold to > somebody as experienced as Dscho, it is likely others would do the > same. > > What can we do to make it easier for people to discover and follow > the best current practice? Are there things in our build > instruction document (e.g. the comment at the top of CMakeLists.txt) > that needs updating? I think Sibi had done a lot of good work to write instruction at the top of CMakeLists.txt, I guess it's a bit too much instruction. The instruction for out of source build was written after the instruction to build in-tree. Should we change the order? I don't really know. I only tried to build Git with CMake only one during the review process. And haven't touched it ever since. 1: https://cmake.org/cmake/help/v3.18/guide/user-interaction/index.html#command-line-cmake-tool -- Danh
