Re: [PATCH] cmake: ignore generated files

["Đoàn Trần Công Danh" <congdanhqx@gmail.com>]

On 2020-09-18 09:21:45-0700, Junio C Hamano <gitster@pobox.com> wrote:
> Đoàn Trần Công Danh  <congdanhqx@gmail.com> 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