* [PATCH] cmake: ignore generated files @ 2020-09-17 20:37 Johannes Schindelin via GitGitGadget 2020-09-17 21:49 ` Junio C Hamano 2020-09-23 17:47 ` Junio C Hamano 0 siblings, 2 replies; 22+ messages in thread From: Johannes Schindelin via GitGitGadget @ 2020-09-17 20:37 UTC (permalink / raw) To: git; +Cc: Johannes Schindelin, Johannes Schindelin From: Johannes Schindelin <johannes.schindelin@gmx.de> When using CMake to generate the files required to build Git in Visual Studio, a bunch of files are generated. We will want to prevent them from being tracked in Git. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> --- Ignore files generated by CMake Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-735%2Fdscho%2Fignore-generated-cmake-files-v1 Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-735/dscho/ignore-generated-cmake-files-v1 Pull-Request: https://github.com/gitgitgadget/git/pull/735 .gitignore | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/.gitignore b/.gitignore index 9673e792db..36f5ac4138 100644 --- a/.gitignore +++ b/.gitignore @@ -239,3 +239,9 @@ Release/ /git.VC.VC.opendb /git.VC.db *.dSYM +*.vcxproj +*.vcxproj.filters +/CMakeCache.txt +/CMakeFiles/ +/*.cmake +/DartConfiguration.tcl base-commit: 54e85e7af1ac9e9a92888060d6811ae767fea1bc -- gitgitgadget ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH] cmake: ignore generated files 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-23 17:47 ` Junio C Hamano 1 sibling, 1 reply; 22+ messages in thread From: Junio C Hamano @ 2020-09-17 21:49 UTC (permalink / raw) To: Johannes Schindelin via GitGitGadget; +Cc: git, Johannes Schindelin "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes: > From: Johannes Schindelin <johannes.schindelin@gmx.de> > > When using CMake to generate the files required to build Git in Visual > Studio, a bunch of files are generated. We will want to prevent them > from being tracked in Git. > > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> > --- > Ignore files generated by CMake > > Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-735%2Fdscho%2Fignore-generated-cmake-files-v1 > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-735/dscho/ignore-generated-cmake-files-v1 > Pull-Request: https://github.com/gitgitgadget/git/pull/735 > > .gitignore | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/.gitignore b/.gitignore > index 9673e792db..36f5ac4138 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -239,3 +239,9 @@ Release/ > /git.VC.VC.opendb > /git.VC.db > *.dSYM > +*.vcxproj > +*.vcxproj.filters > +/CMakeCache.txt > +/CMakeFiles/ > +/*.cmake > +/DartConfiguration.tcl Good to catch these cruft. Does the equivalent of "make distclean" need to be updated to clean them as well, or is it sufficient to ignore the build procedure and just rely on "git clean -f -x"? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] cmake: ignore generated files 2020-09-17 21:49 ` Junio C Hamano @ 2020-09-18 13:11 ` Johannes Schindelin 2020-09-18 15:28 ` Junio C Hamano 0 siblings, 1 reply; 22+ messages in thread From: Johannes Schindelin @ 2020-09-18 13:11 UTC (permalink / raw) To: Junio C Hamano; +Cc: Johannes Schindelin via GitGitGadget, git Hi Junio, On Thu, 17 Sep 2020, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> > writes: > > > From: Johannes Schindelin <johannes.schindelin@gmx.de> > > > > When using CMake to generate the files required to build Git in Visual > > Studio, a bunch of files are generated. We will want to prevent them > > from being tracked in Git. > > > > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> > > --- > > Ignore files generated by CMake > > > > Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-735%2Fdscho%2Fignore-generated-cmake-files-v1 > > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-735/dscho/ignore-generated-cmake-files-v1 > > Pull-Request: https://github.com/gitgitgadget/git/pull/735 > > > > .gitignore | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/.gitignore b/.gitignore > > index 9673e792db..36f5ac4138 100644 > > --- a/.gitignore > > +++ b/.gitignore > > @@ -239,3 +239,9 @@ Release/ > > /git.VC.VC.opendb > > /git.VC.db > > *.dSYM > > +*.vcxproj > > +*.vcxproj.filters > > +/CMakeCache.txt > > +/CMakeFiles/ > > +/*.cmake > > +/DartConfiguration.tcl > > Good to catch these cruft. > > Does the equivalent of "make distclean" need to be updated to clean > them as well, or is it sufficient to ignore the build procedure and > just rely on "git clean -f -x"? Since CMake in conjunction with Visual Studio completely side-steps `make`, I think it would make most sense to ignore `make distclean` in this context and go for `git clean -dfx` instead. Ciao, Dscho ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] cmake: ignore generated files 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-20 17:15 ` Johannes Schindelin 0 siblings, 2 replies; 22+ messages in thread From: Junio C Hamano @ 2020-09-18 15:28 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Johannes Schindelin via GitGitGadget, git Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: >> Good to catch these cruft. >> >> Does the equivalent of "make distclean" need to be updated to clean >> them as well, or is it sufficient to ignore the build procedure and >> just rely on "git clean -f -x"? > > Since CMake in conjunction with Visual Studio completely side-steps > `make`, I think it would make most sense to ignore `make distclean` in > this context and go for `git clean -dfx` instead. I think you misunderstood the question, overlooking the "equivalent" part. I expected that when CMake & VS discards build artifacts, it would not make literal use of "make distclean". After all, it does not use "make all" to build, either. That led me to suspect that CMake & VS may have a build target that is used to discard build artifacts, the moral equivalent to "make distclean". That is where my question "if we are making .gitignore aware of more crufts, don't we need to tell the machinery, which is equivalent to 'make disclean', came from. What I am hearing here is that people with CMake & VS use "git clean -dfx" when they want to go back to the pristine state, unlike those who use "make distclean", and there is nothing to adjust for newly discovered crufts we are leaving on the filesystem. If that is the case, it is 100% fine. It was that I just didn't expect not having a "remove cruft" rule in the build procedure. Thanks. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] cmake: ignore generated files 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-20 17:15 ` Johannes Schindelin 1 sibling, 1 reply; 22+ messages in thread From: Đoàn Trần Công Danh @ 2020-09-18 15:50 UTC (permalink / raw) To: Junio C Hamano Cc: Johannes Schindelin, Johannes Schindelin via GitGitGadget, git On 2020-09-18 08:28:48-0700, Junio C Hamano <gitster@pobox.com> wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > >> Good to catch these cruft. > >> > >> Does the equivalent of "make distclean" need to be updated to clean > >> them as well, or is it sufficient to ignore the build procedure and > >> just rely on "git clean -f -x"? > > > > Since CMake in conjunction with Visual Studio completely side-steps > > `make`, I think it would make most sense to ignore `make distclean` in > > this context and go for `git clean -dfx` instead. > > I think you misunderstood the question, overlooking the "equivalent" > part. > > I expected that when CMake & VS discards build artifacts, it would > not make literal use of "make distclean". After all, it does not > use "make all" to build, either. Actually, in CMake land, people usually do this instead: mkdir build cmake [-Ggenerator] .. <make/ninja/msbuild> 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 think the original CMake proposal didn't touch .gitignore because they run in a separated build-dir. -- Danh ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] cmake: ignore generated files 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-20 17:37 ` Johannes Schindelin 0 siblings, 2 replies; 22+ messages in thread From: Junio C Hamano @ 2020-09-18 16:21 UTC (permalink / raw) To: Đoàn Trần Công Danh Cc: Johannes Schindelin, Johannes Schindelin via GitGitGadget, git Đ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. > > 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. > 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? Thanks. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] cmake: ignore generated files 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 1 sibling, 1 reply; 22+ messages in thread From: Đoàn Trần Công Danh @ 2020-09-19 0:40 UTC (permalink / raw) To: Junio C Hamano Cc: Johannes Schindelin, Johannes Schindelin via GitGitGadget, git 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] cmake: ignore generated files 2020-09-19 0:40 ` Đoàn Trần Công Danh @ 2020-09-19 0:50 ` Junio C Hamano 0 siblings, 0 replies; 22+ messages in thread From: Junio C Hamano @ 2020-09-19 0:50 UTC (permalink / raw) To: Đoàn Trần Công Danh Cc: Johannes Schindelin, Johannes Schindelin via GitGitGadget, git Đoàn Trần Công Danh <congdanhqx@gmail.com> writes: >> 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. Oh, absolutely. It begins with cmake `relative-path-to-CMakeLists.txt` -DCMAKE_BUILD_TYPE=Release Eg. From the root of git source tree `cmake contrib/buildsystems/ ` This will build the git binaries at the root which tells exactly what Dscho did and got him writing the patch in question. You'd need to keep reading to be merely _aware_ that it is possible to do an out-of-tree build, without getting even told that it is the norm in CMake land. We should just remove the above and start the comment seciton with something more like this: When using CMake, building in place is highly discouraged. Instead, create a new "git-build" directory and perform your build there, like this (from the top of the working tree): $ mkdir git-build $ cd git-build $ cmake ../contrib/buildsystems/ -DCMAKE_BUILD_TYPER=Release This will build the git binaries in git-build directory Doing so would reduce the number of choices the user has to make, and reduce the confusion. Thanks. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] cmake: ignore generated files 2020-09-18 16:21 ` Junio C Hamano 2020-09-19 0:40 ` Đoàn Trần Công Danh @ 2020-09-20 17:37 ` Johannes Schindelin 2020-09-23 15:59 ` Junio C Hamano 1 sibling, 1 reply; 22+ messages in thread From: Johannes Schindelin @ 2020-09-20 17:37 UTC (permalink / raw) To: Junio C Hamano Cc: Đoàn Trần Công Danh, Johannes Schindelin via GitGitGadget, git [-- 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] cmake: ignore generated files 2020-09-20 17:37 ` Johannes Schindelin @ 2020-09-23 15:59 ` Junio C Hamano 2020-09-23 20:27 ` Johannes Schindelin 0 siblings, 1 reply; 22+ messages in thread From: Junio C Hamano @ 2020-09-23 15:59 UTC (permalink / raw) To: Johannes Schindelin Cc: Đoàn Trần Công Danh, Johannes Schindelin via GitGitGadget, git 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] cmake: ignore generated files 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-24 10:34 ` Đoàn Trần Công Danh 0 siblings, 2 replies; 22+ messages in thread From: Johannes Schindelin @ 2020-09-23 20:27 UTC (permalink / raw) To: Junio C Hamano Cc: Đoàn Trần Công Danh, Johannes Schindelin via GitGitGadget, git Hi Junio, On Wed, 23 Sep 2020, Junio C Hamano wrote: > 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 It doesn't need to be specified. > 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. 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. That's the opposite direction of making things more convenient for Visual Studio users. Ciao, Dscho ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] cmake: ignore generated files 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 1 sibling, 1 reply; 22+ messages in thread From: Junio C Hamano @ 2020-09-23 20:38 UTC (permalink / raw) To: Johannes Schindelin Cc: Đoàn Trần Công Danh, Johannes Schindelin via GitGitGadget, git Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > 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 Not, "more", but what you are doing is to ensure it is used at only one single place, which is the top-level (and nowhere else, judging from the .gitignore additions). And that is fine---if you were to add .gitignore entries, you cannot leave it up to the end-users where the build happens. So, let's not pretend that you are allowing "more circumstances". Forcing a single choice to make things predictable is fine, but let's explain it as such, so that people won't be confused into thinking that they can follow their experiences gained from using CMake in other projects that lets them build in a separate directory. The other things in our project, including the patterns added to .gitignore with the patch in question, are not set up to allow that. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] cmake: ignore generated files 2020-09-23 20:38 ` Junio C Hamano @ 2020-09-25 6:40 ` Johannes Schindelin 0 siblings, 0 replies; 22+ messages in thread From: Johannes Schindelin @ 2020-09-25 6:40 UTC (permalink / raw) To: Junio C Hamano Cc: Đoàn Trần Công Danh, Johannes Schindelin via GitGitGadget, git Hi Junio, On Wed, 23 Sep 2020, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > 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 > > Not, "more", but what you are doing is to ensure it is used at only > one single place, which is the top-level (and nowhere else, judging > from the .gitignore additions). > > And that is fine---if you were to add .gitignore entries, you cannot > leave it up to the end-users where the build happens. > > So, let's not pretend that you are allowing "more circumstances". > Forcing a single choice to make things predictable is fine, but > let's explain it as such, so that people won't be confused into > thinking that they can follow their experiences gained from using > CMake in other projects that lets them build in a separate > directory. The other things in our project, including the > patterns added to .gitignore with the patch in question, are not set > up to allow that. While I respectfully disagree that I force a single choice on anybody, I do agree that there is value in having one recommended route that is well supported. Thanks, Dscho ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] cmake: ignore generated files 2020-09-23 20:27 ` Johannes Schindelin 2020-09-23 20:38 ` Junio C Hamano @ 2020-09-24 10:34 ` Đoàn Trần Công Danh 2020-09-25 5:02 ` Johannes Schindelin 1 sibling, 1 reply; 22+ messages in thread From: Đoàn Trần Công Danh @ 2020-09-24 10:34 UTC (permalink / raw) To: Johannes Schindelin Cc: Junio C Hamano, Johannes Schindelin via GitGitGadget, git Hi Dscho, 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] 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. I think the default UX with CMake on Windows is building project out of tree. > 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. 1: https://cmake.org/runningcmake/ 2: https://docs.microsoft.com/en-us/cpp/build/cmake-projects-in-visual-studio?view=vs-2019 -- Danh ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] cmake: ignore generated files 2020-09-24 10:34 ` Đoàn Trần Công Danh @ 2020-09-25 5:02 ` Johannes Schindelin 0 siblings, 0 replies; 22+ messages in thread From: Johannes Schindelin @ 2020-09-25 5:02 UTC (permalink / raw) To: Đoàn Trần Công Danh Cc: Junio C Hamano, Johannes Schindelin via GitGitGadget, git [-- Attachment #1: Type: text/plain, Size: 3877 bytes --] 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@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`. > 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 > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] cmake: ignore generated files 2020-09-18 15:28 ` Junio C Hamano 2020-09-18 15:50 ` Đoàn Trần Công Danh @ 2020-09-20 17:15 ` Johannes Schindelin 2020-09-21 22:46 ` Junio C Hamano 1 sibling, 1 reply; 22+ messages in thread From: Johannes Schindelin @ 2020-09-20 17:15 UTC (permalink / raw) To: Junio C Hamano; +Cc: Johannes Schindelin via GitGitGadget, git Hi Junio, On Fri, 18 Sep 2020, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > >> Good to catch these cruft. > >> > >> Does the equivalent of "make distclean" need to be updated to clean > >> them as well, or is it sufficient to ignore the build procedure and > >> just rely on "git clean -f -x"? > > > > Since CMake in conjunction with Visual Studio completely side-steps > > `make`, I think it would make most sense to ignore `make distclean` in > > this context and go for `git clean -dfx` instead. > > I think you misunderstood the question, overlooking the "equivalent" > part. > > I expected that when CMake & VS discards build artifacts, it would > not make literal use of "make distclean". After all, it does not > use "make all" to build, either. > > That led me to suspect that CMake & VS may have a build target that > is used to discard build artifacts, the moral equivalent to "make > distclean". That is where my question "if we are making .gitignore > aware of more crufts, don't we need to tell the machinery, which is > equivalent to 'make disclean', came from. > > What I am hearing here is that people with CMake & VS use "git clean > -dfx" when they want to go back to the pristine state, unlike those > who use "make distclean", and there is nothing to adjust for newly > discovered crufts we are leaving on the filesystem. Yes, that is my understanding. > If that is the case, it is 100% fine. It was that I just didn't > expect not having a "remove cruft" rule in the build procedure. Thanks, Dscho ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] cmake: ignore generated files 2020-09-20 17:15 ` Johannes Schindelin @ 2020-09-21 22:46 ` Junio C Hamano 2020-09-23 13:08 ` Johannes Schindelin 0 siblings, 1 reply; 22+ messages in thread From: Junio C Hamano @ 2020-09-21 22:46 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Johannes Schindelin via GitGitGadget, git Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: >> What I am hearing here is that people with CMake & VS use "git clean >> -dfx" when they want to go back to the pristine state, unlike those >> who use "make distclean", and there is nothing to adjust for newly >> discovered crufts we are leaving on the filesystem. > > Yes, that is my understanding. I do not know if you have read other messages in the thread, but my current understanding of what we learned in this thread [*1*] is that those who use CMake, especially in a tree like ours that has its own Makefiles, (sh|w)ould create a throw-away directory and run build there, so even "git clean -dxf" is not part of their "clean" procedure. [Footnote] *1* https://lore.kernel.org/git/20200919004030.GB1837@danh.dev/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] cmake: ignore generated files 2020-09-21 22:46 ` Junio C Hamano @ 2020-09-23 13:08 ` Johannes Schindelin 2020-09-24 9:19 ` SZEDER Gábor 0 siblings, 1 reply; 22+ messages in thread From: Johannes Schindelin @ 2020-09-23 13:08 UTC (permalink / raw) To: Junio C Hamano; +Cc: Johannes Schindelin via GitGitGadget, git Hi Junio, On Mon, 21 Sep 2020, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > >> What I am hearing here is that people with CMake & VS use "git clean > >> -dfx" when they want to go back to the pristine state, unlike those > >> who use "make distclean", and there is nothing to adjust for newly > >> discovered crufts we are leaving on the filesystem. > > > > Yes, that is my understanding. > > I do not know if you have read other messages in the thread, I did. > but my current understanding of what we learned in this thread [*1*] is > that those who use CMake, especially in a tree like ours that has its > own Makefiles, (sh|w)ould create a throw-away directory and run build > there, so even "git clean -dxf" is not part of their "clean" procedure. Well, our CMake support does not extend to generating Makefiles: we specifically target only Windows withour CMake support, and since there is no need to help developers who already use the Git for Windows SDK or Cygwin, we really focus only on supporting Visual Studio. In that respect, I think that all that talk about Makefiles isn't quite spot on. In any case, `git clean -dfx` strikes me as a perfectly acceptable equivalent of `make clean` when no `make` is available, as is the case in Visual Studio's case. Ciao, Dscho > [Footnote] > > *1* https://lore.kernel.org/git/20200919004030.GB1837@danh.dev/ > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] cmake: ignore generated files 2020-09-23 13:08 ` Johannes Schindelin @ 2020-09-24 9:19 ` SZEDER Gábor 2020-09-24 17:11 ` Junio C Hamano 0 siblings, 1 reply; 22+ messages in thread From: SZEDER Gábor @ 2020-09-24 9:19 UTC (permalink / raw) To: Johannes Schindelin Cc: Junio C Hamano, Johannes Schindelin via GitGitGadget, git On Wed, Sep 23, 2020 at 03:08:26PM +0200, Johannes Schindelin wrote: > In any case, `git clean -dfx` strikes me as a perfectly acceptable > equivalent of `make clean` when no `make` is available, as is the case in > Visual Studio's case. Not at all: 'make (dist)clean' only removes build artifacts and leaves untracked files intact, while 'git clean -dfx' removes untracked files as well, so using the latter instead of the former might easily lead to data loss. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] cmake: ignore generated files 2020-09-24 9:19 ` SZEDER Gábor @ 2020-09-24 17:11 ` Junio C Hamano 0 siblings, 0 replies; 22+ messages in thread From: Junio C Hamano @ 2020-09-24 17:11 UTC (permalink / raw) To: SZEDER Gábor Cc: Johannes Schindelin, Johannes Schindelin via GitGitGadget, git SZEDER Gábor <szeder.dev@gmail.com> writes: > On Wed, Sep 23, 2020 at 03:08:26PM +0200, Johannes Schindelin wrote: >> In any case, `git clean -dfx` strikes me as a perfectly acceptable >> equivalent of `make clean` when no `make` is available, as is the case in >> Visual Studio's case. > > Not at all: 'make (dist)clean' only removes build artifacts and leaves > untracked files intact, while 'git clean -dfx' removes untracked files > as well, so using the latter instead of the former might easily lead to > data loss. Well, with the patch in question applied, "git clean -f" would be usable as a poor-man's replacement that removes "ignored and expendable" paths that match patterns listed in the file, so... ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] cmake: ignore generated files 2020-09-17 20:37 [PATCH] cmake: ignore generated files Johannes Schindelin via GitGitGadget 2020-09-17 21:49 ` Junio C Hamano @ 2020-09-23 17:47 ` Junio C Hamano 2020-09-23 17:53 ` Junio C Hamano 1 sibling, 1 reply; 22+ messages in thread From: Junio C Hamano @ 2020-09-23 17:47 UTC (permalink / raw) To: Johannes Schindelin via GitGitGadget; +Cc: git, Johannes Schindelin "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes: > From: Johannes Schindelin <johannes.schindelin@gmx.de> > > When using CMake to generate the files required to build Git in Visual > Studio, a bunch of files are generated. We will want to prevent them > from being tracked in Git. If we were to go this route, let's * update the log message to say that we assume we will use CMake to build in-place. * update the comment in the top part of the CMakeList.txt that suggests it is a possibility to use it from subdirectories. * optionally, update the same comment to recommend "clean -xdf" as a way to bring the source tree back to the pristine state. Will queue with a tentative attempt to do the first bullet point to save one roundtip, something like: When using CMake to generate the files required to build Git in-place for Visual Studio, ... Other two points needs help from others (iow, I won't do so myself right now). Thanks. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] cmake: ignore generated files 2020-09-23 17:47 ` Junio C Hamano @ 2020-09-23 17:53 ` Junio C Hamano 0 siblings, 0 replies; 22+ messages in thread From: Junio C Hamano @ 2020-09-23 17:53 UTC (permalink / raw) To: Johannes Schindelin via GitGitGadget; +Cc: git, Johannes Schindelin Junio C Hamano <gitster@pobox.com> writes: > "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> > writes: > >> From: Johannes Schindelin <johannes.schindelin@gmx.de> >> >> When using CMake to generate the files required to build Git in Visual >> Studio, a bunch of files are generated. We will want to prevent them >> from being tracked in Git. > > If we were to go this route, let's > > * update the log message to say that we assume we will use CMake to > build in-place. > > * update the comment in the top part of the CMakeList.txt that > suggests it is a possibility to use it from subdirectories. Sorry, sent too soon. Either s/update/remove/, or to say that this project assume things are built in-place. > * optionally, update the same comment to recommend "clean -xdf" > as a way to bring the source tree back to the pristine state. > > Will queue with a tentative attempt to do the first bullet point to > save one roundtip, something like: > > When using CMake to generate the files required to build Git > in-place for Visual Studio, ... > > Other two points needs help from others (iow, I won't do so myself > right now). > > Thanks. ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2020-09-25 10:55 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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).