Re: [PATCH] cmake: ignore generated files

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

 



Hi Danh,

On Thu, 24 Sep 2020, Đoàn Trần Công Danh wrote:

> On 2020-09-23 22:27:17+0200, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote:
> > > ... 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.
> >
> > All I want is for the CMake support to be easier to use, yet we go in the
> > opposite direction: instead of allowing to use CMake under more
> > circumstances (which actually *works*, we just don't have the appropriate
> > patterns in our `.gitignore` yet to avoid adding and committing the
> > generated files), we now seem to intend to require a separate build
> > directory.
>
> I've left Windows development land for a long time.
> So, please take below discussion with grain of salt.
>
> When I was there, CMake Users on Windows mostly used CMake-GUI to
> generate build system for CMake since running CMake as CLI in Windows
> takes too much hassle.
>
> When I was there, CMake-GUI shows the option to choose build directories
> explicitly, and whenever the source directories changed, the build
> directories also changed, with some [-/]build added into sourcedir [1]

In my tests, the build directory was left empty. When I clicked the button
next to it, it defaulted to the same directory as `CMakeLists.txt`:
`contrib/buildsystems/`.

I might be holding this thing wrong, but if I don't, then we would
actually have to add a _different_ set of patterns to `.gitignore`.

> I heard that nowaday, CMake is supported natively with MSVC, I don't
> know what is the default option when using CMake with MSVC, but from
> the history of MSVC always supports building out of tree, and
> information for Microsoft Docs [2]:
>
> 	Click the Show All Files button at the top of Solution
> 	Explorer to see all the CMake-generated output in the
> 	out/build/<config> folders.

Oh wow, I missed this. And it looks promising: when I open a fresh
checkout of current git/git's `master` branch in a freshly updated Visual
Studio 2019, it finds the CMakeLists.txt file automatically.

But that's where the happy news end: it stops with the error message:

CMake Error at [...]\contrib\buildsystems\CMakeLists.txt:46 (message):
  sh: shell interpreter was not found in your path, please install one.On
  Windows, you can get it as part of 'Git for Windows' install at
  https://gitforwindows.org/	git
[...]\contrib\buildsystems\CMakeLists.txt	46

So there's a bit of work left to do for me.

> I think the default UX with CMake on Windows is building project out
> of tree.

Indeed, it _does_ create `contrib/buildsystems/out/` and starts outputting
files to `contrib/buildsystems/out/build/x64-Debug (default)/`.

Seeing as using Visual Studio's built-in CMake support is much more
convenient to use than a separate CMake installation, I reconsidered my
original idea, and now think that y'all are right, my current patch isn't
the best way forward. I'll rework the patch into a proper patch series
that takes into account what I learned today.

> > That's the opposite direction of making things more convenient for Visual
> > Studio users.
>
> So, I don't think we would provide them more convenient with this change.

Indeed. And more convenience is what I want, I don't want developers on
Windows to struggle with the tooling when all they want to do is to
contribute to Git.

Thank you,
Dscho

>
>
> 1: https://cmake.org/runningcmake/
> 2: https://docs.microsoft.com/en-us/cpp/build/cmake-projects-in-visual-studio?view=vs-2019
>
> --
> Danh
>

[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