All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
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: Wed, 23 Sep 2020 08:59:32 -0700	[thread overview]
Message-ID: <xmqqr1qsjxgb.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.2009201916040.5061@tvgsbejvaqbjf.bet> (Johannes Schindelin's message of "Sun, 20 Sep 2020 19:37:41 +0200 (CEST)")

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

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

Sorry, but that does not sound like a convincing excuse because ...

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

... if the build directory needs to be specified anyway, there don't
seem to be a big difference between telling them to create an empty
build place and use it and telling them to point at the source tree
itself, so ...

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

... the above sounds like the argument concentrates too much on
where the build directory is (i.e. between "in place" and "a
throw-away directory next door"), which sounds like much smaller
point compared to the other things that needs to be improved in the
VS users.  And making a choice against what is recommended as best
practice...?  I dunno.


  reply	other threads:[~2020-09-23 15:59 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
2020-09-23 15:59             ` Junio C Hamano [this message]
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=xmqqr1qsjxgb.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=congdanhqx@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.