Re: [PATCH] cmake: ignore generated files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Đ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?  I take the "people
usually do" is the best current practice?

> 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.

> 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?

Thanks.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux