git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Đoàn Trần Công Danh" <congdanhqx@gmail.com>,
	"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH] cmake: ignore generated files
Date: Sun, 20 Sep 2020 19:37:41 +0200 (CEST)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.2009201916040.5061@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <xmqq7dsrnjhi.fsf@gitster.c.googlers.com>

[-- Attachment #1: Type: text/plain, Size: 3485 bytes --]

Hi Junio,

On Fri, 18 Sep 2020, Junio C Hamano 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?  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.

It is discouraged, but not disallowed.

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

Indeed, when asking CMake to generate a Makefile twice, there will be a
problem.

But so far, we successfully resisted making the CMake support powerful
enough to support anything but Windows and Visual C.

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

That's because Dscho does not like the separate build directory, even if
they know that in the CMake world, it is kind of expected.

It's just that it would be super convenient for Visual Studio users to
just generate their project files in-place. That's why I started down that
road.

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

Ideally, we would tell Visual Studio users to "just install CMake, start
its GUI, direct it to the Git source, configure and generate". Alas, it is
not that easy:

- The `SH_EXE` is not found by default (`C:\Program Files\Git\bin\sh.exe`
  should be used in the vast majority of the cases),
- If the build directory is left unspecified, the non-writable `C:\Program
  Files\CMake\bin` directory is used,
- The `compat\vcbuild\vcpkg` system is not initialized automatically, and
  even if the user initialized it, the dependencies (such as expat, zlib)
  are still not found.

I would like to make things easier, and forcing users to use a separate
build directory (that needs to be outside of the Git source tree because
our `.gitignore` does not handle it well) would go the other direction, I
fear.

In short: this `.gitignore` is but one small step in the endeavor to make
it more convenient for Visual Studio users to contribute.

Ciao,
Dscho

  parent reply	other threads:[~2020-09-21 22:52 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
2020-09-19  0:50             ` Junio C Hamano
2020-09-20 17:37           ` Johannes Schindelin [this message]
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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=nycvar.QRO.7.76.6.2009201916040.5061@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=congdanhqx@gmail.com \
    --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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).