From: "Đoàn Trần Công Danh" <congdanhqx@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH] cmake: ignore generated files
Date: Sat, 19 Sep 2020 07:40:30 +0700 [thread overview]
Message-ID: <20200919004030.GB1837@danh.dev> (raw)
In-Reply-To: <xmqq7dsrnjhi.fsf@gitster.c.googlers.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
next prev parent reply other threads:[~2020-09-19 0:40 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-17 20:37 [PATCH] cmake: ignore generated files Johannes Schindelin via GitGitGadget
2020-09-17 21:49 ` Junio C Hamano
2020-09-18 13:11 ` Johannes Schindelin
2020-09-18 15:28 ` Junio C Hamano
2020-09-18 15:50 ` Đoàn Trần Công Danh
2020-09-18 16:21 ` Junio C Hamano
2020-09-19 0:40 ` Đoàn Trần Công Danh [this message]
2020-09-19 0:50 ` Junio C Hamano
2020-09-20 17:37 ` Johannes Schindelin
2020-09-23 15:59 ` Junio C Hamano
2020-09-23 20:27 ` Johannes Schindelin
2020-09-23 20:38 ` Junio C Hamano
2020-09-25 6:40 ` Johannes Schindelin
2020-09-24 10:34 ` Đoàn Trần Công Danh
2020-09-25 5:02 ` Johannes Schindelin
2020-09-20 17:15 ` Johannes Schindelin
2020-09-21 22:46 ` Junio C Hamano
2020-09-23 13:08 ` Johannes Schindelin
2020-09-24 9:19 ` SZEDER Gábor
2020-09-24 17:11 ` Junio C Hamano
2020-09-23 17:47 ` Junio C Hamano
2020-09-23 17:53 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200919004030.GB1837@danh.dev \
--to=congdanhqx@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).