Re: [PATCH] cmake: ignore generated files
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Sep 25, 2020, 05:02 UTC
- Message-ID
- <nycvar.QRO.7.76.6.2009250650280.5061@tvgsbejvaqbjf.bet>
- In-Reply-To
- <20200924103437.GA18952@danh.dev>
Hi Danh,
On Thu, 24 Sep 2020, Đoàn Trần Công Danh wrote:
Show 25 quoted lines
> On 2020-09-23 22:27:17+0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> 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`.
Show 8 quoted lines
> 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
Show 8 quoted lines
> > > 1: https://cmake.org/runningcmake/ > 2: https://docs.microsoft.com/en-us/cpp/build/cmake-projects-in-visual-studio?view=vs-2019 > > -- > Danh >