git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
* [PATCH 00/10] CMake and Visual Studio
@ 2020-09-25 14:28 Johannes Schindelin via GitGitGadget
  2020-09-25 14:28 ` [PATCH 01/10] cmake: ignore files generated by CMake as run in " Johannes Schindelin via GitGitGadget
                   ` (10 more replies)
  0 siblings, 11 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-25 14:28 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Johannes Schindelin

The intention of this patch series is to make it as easy as possible for a
Visual Studio user to start building Git from scratch. The idea is to

 * clone Git's source code,
 * open it in Visual Studio via File>Open>Folder...
 * let CMake configure things (and vcpkg build the dependencies, which will
   take a while), and
 * start the build.

It does require a Git for Windows to be installed (so that the source can be
cloned, but also to run the shell script parts of the CMake configuration),
and also to run the tests.

This patch series replaces the patch "Ignore files generated by CMake" I
sent via https://github.com/gitgitgadget/git/pull/735.

Johannes Schindelin (10):
  cmake: ignore files generated by CMake as run in Visual Studio
  cmake: do find Git for Windows' shell interpreter
  cmake: ensure that the `vcpkg` packages are found on Windows
  cmake: fall back to using `vcpkg`'s `msgfmt.exe` on Windows
  cmake: quote the path accurately when editing `test-lib.sh`
  cmake (Windows): let the `.dll` files are found when running the tests
  cmake (Windows): complain when encountering an unknown compiler
  cmake (Windows): initialize vcpkg/build dependencies automatically
  cmake (Windows): recommend using Visual Studio's built-in CMake
    support
  hashmap_for_each_entry(): work around MSVC's run-time check failure #3

 .gitignore                          |  1 +
 attr.c                              |  2 +-
 blame.c                             |  4 +--
 bloom.c                             |  2 +-
 builtin/describe.c                  |  2 +-
 builtin/difftool.c                  |  2 +-
 builtin/fast-import.c               |  2 +-
 builtin/sparse-checkout.c           |  6 ++--
 config.c                            |  2 +-
 contrib/buildsystems/CMakeLists.txt | 43 +++++++++++++++++++++++++----
 merge-recursive.c                   | 10 +++----
 name-hash.c                         |  2 +-
 revision.c                          |  4 +--
 submodule-config.c                  |  2 +-
 t/helper/test-hashmap.c             |  2 +-
 t/helper/test-lazy-init-name-hash.c |  4 +--
 16 files changed, 62 insertions(+), 28 deletions(-)


base-commit: e1cfff676549cdcd702cbac105468723ef2722f4
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-738%2Fdscho%2Fcmake-and-visual-studio-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-738/dscho/cmake-and-visual-studio-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/738
-- 
gitgitgadget

^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH 01/10] cmake: ignore files generated by CMake as run in Visual Studio
  2020-09-25 14:28 [PATCH 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
@ 2020-09-25 14:28 ` Johannes Schindelin via GitGitGadget
  2020-09-25 14:28 ` [PATCH 02/10] cmake: do find Git for Windows' shell interpreter Johannes Schindelin via GitGitGadget
                   ` (9 subsequent siblings)
  10 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-25 14:28 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

As of recent Visual Studio versions, CMake support is built-in:
https://docs.microsoft.com/en-us/cpp/build/cmake-projects-in-visual-studio?view=vs-2019

All that needs to be done is to open the worktree as a folder, and
Visual Studio will find the `CMakeLists.txt` file and automatically
generate the project files.

Let's ignore the entirety of those generated files.

Helped-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index d0f692a355..6521f3cf22 100644
--- a/.gitignore
+++ b/.gitignore
@@ -241,3 +241,4 @@ Release/
 /git.VC.VC.opendb
 /git.VC.db
 *.dSYM
+/contrib/buildsystems/out
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH 02/10] cmake: do find Git for Windows' shell interpreter
  2020-09-25 14:28 [PATCH 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
  2020-09-25 14:28 ` [PATCH 01/10] cmake: ignore files generated by CMake as run in " Johannes Schindelin via GitGitGadget
@ 2020-09-25 14:28 ` Johannes Schindelin via GitGitGadget
  2020-09-25 16:25   ` Sibi Siddharthan
  2020-09-25 14:28 ` [PATCH 03/10] cmake: ensure that the `vcpkg` packages are found on Windows Johannes Schindelin via GitGitGadget
                   ` (8 subsequent siblings)
  10 siblings, 1 reply; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-25 14:28 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

By default, Git for Windows does not install its `sh.exe` into the
`PATH`. However, our current `CMakeLists.txt` expects to find a shell
interpreter in the `PATH`.

So let's fall back to looking in the default location where Git for
Windows _does_ install a relatively convenient `sh.exe`:
`C:\Program Files\Git\bin\sh.exe`

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index 5007f173f1..d14fa4f3dc 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -43,8 +43,11 @@ set(CMAKE_SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/../..)
 
 find_program(SH_EXE sh)
 if(NOT SH_EXE)
-	message(FATAL_ERROR "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/")
+	set(SH_EXE "C:/Program Files/Git/bin/sh.exe")
+	if(NOT EXISTS ${SH_EXE})
+		message(FATAL_ERROR "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/")
+	endif()
 endif()
 
 #Create GIT-VERSION-FILE using GIT-VERSION-GEN
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH 03/10] cmake: ensure that the `vcpkg` packages are found on Windows
  2020-09-25 14:28 [PATCH 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
  2020-09-25 14:28 ` [PATCH 01/10] cmake: ignore files generated by CMake as run in " Johannes Schindelin via GitGitGadget
  2020-09-25 14:28 ` [PATCH 02/10] cmake: do find Git for Windows' shell interpreter Johannes Schindelin via GitGitGadget
@ 2020-09-25 14:28 ` Johannes Schindelin via GitGitGadget
  2020-09-25 14:28 ` [PATCH 04/10] cmake: fall back to using `vcpkg`'s `msgfmt.exe` " Johannes Schindelin via GitGitGadget
                   ` (7 subsequent siblings)
  10 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-25 14:28 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

On Windows, we use the `vcpkg` project to manage the dependencies, via
`compat/vcbuild/`. Let's make sure that these dependencies are found by
default.

This is needed because we are about to recommend loading the Git
worktree as a folder into Visual Studio, relying on the automatic CMake
support (which would make it relatively cumbersome to adjust the search
path used by CMake manually).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index d14fa4f3dc..16014ac4f7 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -40,6 +40,13 @@ cmake_minimum_required(VERSION 3.14)
 
 #set the source directory to root of git
 set(CMAKE_SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/../..)
+if(WIN32)
+	set(VCPKG_DIR "${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg")
+	list(APPEND CMAKE_PREFIX_PATH "${VCPKG_DIR}/installed/x64-windows")
+
+	# In the vcpkg edition, we need this to be able to link to libcurl
+	set(CURL_NO_CURL_CMAKE ON)
+endif()
 
 find_program(SH_EXE sh)
 if(NOT SH_EXE)
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH 04/10] cmake: fall back to using `vcpkg`'s `msgfmt.exe` on Windows
  2020-09-25 14:28 [PATCH 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                   ` (2 preceding siblings ...)
  2020-09-25 14:28 ` [PATCH 03/10] cmake: ensure that the `vcpkg` packages are found on Windows Johannes Schindelin via GitGitGadget
@ 2020-09-25 14:28 ` Johannes Schindelin via GitGitGadget
  2020-09-25 14:28 ` [PATCH 05/10] cmake: quote the path accurately when editing `test-lib.sh` Johannes Schindelin via GitGitGadget
                   ` (6 subsequent siblings)
  10 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-25 14:28 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

We are already relying on `vcpkg` to manage our dependencies, including
`libiconv`. Let's also use the `msgfmt.exe` from there.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index 16014ac4f7..acb197fba5 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -155,7 +155,11 @@ endif()
 
 find_program(MSGFMT_EXE msgfmt)
 if(NOT MSGFMT_EXE)
-	message(WARNING "Text Translations won't be build")
+	set(MSGFMT_EXE ${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg/downloads/tools/msys2/msys64/usr/bin/msgfmt.exe)
+	if(NOT EXISTS ${MSGFMT_EXE})
+		message(WARNING "Text Translations won't be build")
+		unset(MSGFMT_EXE)
+	endif()
 endif()
 
 #Force all visual studio outputs to CMAKE_BINARY_DIR
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH 05/10] cmake: quote the path accurately when editing `test-lib.sh`
  2020-09-25 14:28 [PATCH 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                   ` (3 preceding siblings ...)
  2020-09-25 14:28 ` [PATCH 04/10] cmake: fall back to using `vcpkg`'s `msgfmt.exe` " Johannes Schindelin via GitGitGadget
@ 2020-09-25 14:28 ` Johannes Schindelin via GitGitGadget
  2020-09-25 14:28 ` [PATCH 06/10] cmake (Windows): let the `.dll` files are found when running the tests Johannes Schindelin via GitGitGadget
                   ` (5 subsequent siblings)
  10 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-25 14:28 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

By default, the build directory will be called something like
`contrib/buildsystems/out/build/x64-Debug (default)` (note the space and
the parentheses). We need to make sure that such a path is quoted
properly when editing the assignment of the `GIT_BUILD_DIR` variable.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index acb197fba5..e66ae137c2 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -952,7 +952,7 @@ if(NOT ${CMAKE_BINARY_DIR}/CMakeCache.txt STREQUAL ${CACHE_PATH})
 	file(WRITE ${CMAKE_BINARY_DIR}/CTestCustom.cmake
 		"file(STRINGS ${CMAKE_SOURCE_DIR}/t/test-lib.sh GIT_BUILD_DIR_REPL REGEX \"GIT_BUILD_DIR=(.*)\")\n"
 		"file(STRINGS ${CMAKE_SOURCE_DIR}/t/test-lib.sh content NEWLINE_CONSUME)\n"
-		"string(REPLACE \"\${GIT_BUILD_DIR_REPL}\" \"GIT_BUILD_DIR=\\\"$TEST_DIRECTORY\\\"/../${BUILD_DIR_RELATIVE}\" content \"\${content}\")\n"
+		"string(REPLACE \"\${GIT_BUILD_DIR_REPL}\" \"GIT_BUILD_DIR=\\\"$TEST_DIRECTORY/../${BUILD_DIR_RELATIVE}\\\"\" content \"\${content}\")\n"
 		"file(WRITE ${CMAKE_SOURCE_DIR}/t/test-lib.sh \${content})")
 	#misc copies
 	file(COPY ${CMAKE_SOURCE_DIR}/t/chainlint.sed DESTINATION ${CMAKE_BINARY_DIR}/t/)
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH 06/10] cmake (Windows): let the `.dll` files are found when running the tests
  2020-09-25 14:28 [PATCH 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                   ` (4 preceding siblings ...)
  2020-09-25 14:28 ` [PATCH 05/10] cmake: quote the path accurately when editing `test-lib.sh` Johannes Schindelin via GitGitGadget
@ 2020-09-25 14:28 ` Johannes Schindelin via GitGitGadget
  2020-09-25 19:48   ` Eric Sunshine
  2020-09-25 14:28 ` [PATCH 07/10] cmake (Windows): complain when encountering an unknown compiler Johannes Schindelin via GitGitGadget
                   ` (4 subsequent siblings)
  10 siblings, 1 reply; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-25 14:28 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Contrary to Unix-ish platforms, the dependencies' shared libraries are
not usually found in one central place. In our case, since we use
`vcpkg`, they are to be found inside the `compat/vcbuild/vcpkg/` tree.

Let's make sure that they are in the search path when running the tests.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index e66ae137c2..5a4e0ccb01 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -942,6 +942,9 @@ file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "X='${EXE_EXTENSION}'\n")
 file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "NO_GETTEXT='${NO_GETTEXT}'\n")
 file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "RUNTIME_PREFIX='${RUNTIME_PREFIX}'\n")
 file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "NO_PYTHON='${NO_PYTHON}'\n")
+if(WIN32)
+	file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "PATH=\"$PATH:$TEST_DIRECTORY/../compat/vcbuild/vcpkg/installed/x64-windows/bin\"\n")
+endif()
 
 #Make the tests work when building out of the source tree
 get_filename_component(CACHE_PATH ${CMAKE_CURRENT_LIST_DIR}/../../CMakeCache.txt ABSOLUTE)
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH 07/10] cmake (Windows): complain when encountering an unknown compiler
  2020-09-25 14:28 [PATCH 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                   ` (5 preceding siblings ...)
  2020-09-25 14:28 ` [PATCH 06/10] cmake (Windows): let the `.dll` files are found when running the tests Johannes Schindelin via GitGitGadget
@ 2020-09-25 14:28 ` Johannes Schindelin via GitGitGadget
  2020-09-25 17:29   ` Sibi Siddharthan
  2020-09-25 14:28 ` [PATCH 08/10] cmake (Windows): initialize vcpkg/build dependencies automatically Johannes Schindelin via GitGitGadget
                   ` (3 subsequent siblings)
  10 siblings, 1 reply; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-25 14:28 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

We have some custom handling regarding the link options, which are
specific to each compiler.

Therefore: let's not just continue without setting the link options when
configuring for a currently unhandled compiler, but error out.

Note: for some reason, the `invalidcontinue.obj` trick seems not to work
in this developer's hands when building Git in Debug mode: the assertion
dialog that is supposed to be suppressed still pops up, complaining
about the `entry` variable being uninitialized when it is used in
`config.c`'s line 1961.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index 5a4e0ccb01..d21849b730 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -620,6 +620,8 @@ if(WIN32)
 		target_link_options(common-main PUBLIC -municode -Wl,-nxcompat -Wl,-dynamicbase -Wl,-entry:wmainCRTStartup -Wl,invalidcontinue.obj)
 	elseif(CMAKE_C_COMPILER_ID STREQUAL "MSVC")
 		target_link_options(common-main PUBLIC /IGNORE:4217 /IGNORE:4049 /NOLOGO /ENTRY:wmainCRTStartup /SUBSYSTEM:CONSOLE invalidcontinue.obj)
+	else()
+		message(FATAL_ERROR "Unhandled compiler: ${CMAKE_C_COMPILER_ID}")
 	endif()
 elseif(UNIX)
 	target_link_libraries(common-main pthread rt)
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH 08/10] cmake (Windows): initialize vcpkg/build dependencies automatically
  2020-09-25 14:28 [PATCH 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                   ` (6 preceding siblings ...)
  2020-09-25 14:28 ` [PATCH 07/10] cmake (Windows): complain when encountering an unknown compiler Johannes Schindelin via GitGitGadget
@ 2020-09-25 14:28 ` Johannes Schindelin via GitGitGadget
  2020-09-30  5:05   ` Sibi Siddharthan
  2020-09-25 14:28 ` [PATCH 09/10] cmake (Windows): recommend using Visual Studio's built-in CMake support Johannes Schindelin via GitGitGadget
                   ` (2 subsequent siblings)
  10 siblings, 1 reply; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-25 14:28 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The idea of having CMake support in Git's source tree is to enable
contributors on Windows to start contributing with little effort. To
that end, we just added some sensible defaults that will let users open
the worktree in Visual Studio and start building.

This expects the dependencies (such as zlib) to be available already,
though. If they are not available, we expect the user to run
`compat/vcbuild/vcpkg_install.bat`.

Rather than requiring this step to be manual, detect the situation and
run it as part of the CMake configuration step.

This concludes our journey to make it as effortless as possible to start
developing Git in Visual Studio: all the developer needs to do is to
clone Git's repository, open the worktree via `File>Open>Folder...` and
wait for CMake to finish configuring.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index d21849b730..1eaeb8b8e0 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -42,6 +42,10 @@ cmake_minimum_required(VERSION 3.14)
 set(CMAKE_SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/../..)
 if(WIN32)
 	set(VCPKG_DIR "${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg")
+	if(NOT EXISTS ${VCPKG_DIR})
+		message("Initializinge vcpkg and building the Git's dependencies (this will take a while...)")
+		execute_process(COMMAND ${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg_install.bat)
+	endif()
 	list(APPEND CMAKE_PREFIX_PATH "${VCPKG_DIR}/installed/x64-windows")
 
 	# In the vcpkg edition, we need this to be able to link to libcurl
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH 09/10] cmake (Windows): recommend using Visual Studio's built-in CMake support
  2020-09-25 14:28 [PATCH 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                   ` (7 preceding siblings ...)
  2020-09-25 14:28 ` [PATCH 08/10] cmake (Windows): initialize vcpkg/build dependencies automatically Johannes Schindelin via GitGitGadget
@ 2020-09-25 14:28 ` Johannes Schindelin via GitGitGadget
  2020-09-25 18:22   ` Junio C Hamano
  2020-09-25 14:28 ` [PATCH 10/10] hashmap_for_each_entry(): work around MSVC's run-time check failure #3 Johannes Schindelin via GitGitGadget
  2020-09-26 21:32 ` [PATCH v2 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
  10 siblings, 1 reply; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-25 14:28 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

It is a lot more convenient to use than having to specify the
configuration in CMake manually (does not matter whether using the
command-line or CMake's GUI).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index 1eaeb8b8e0..442b4e69ad 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -4,7 +4,17 @@
 
 #[[
 
-Instructions to run CMake:
+Instructions how to use this in Visual Studio:
+
+Open the worktree as a folder. Visual Studio 2019 and later will detect
+the CMake configuration automatically and set everything up for you,
+ready to build. You can then run the tests in `t/` via a regular Git Bash.
+
+Note: Visual Studio also has the option of opening the CMake configuration
+directly; Using this option, Visual Studio will not find the source code,
+though, therefore the `File>Open>Folder...` option is preferred.
+
+Instructions to run CMake manually:
 
 cmake `relative-path-to-CMakeLists.txt` -DCMAKE_BUILD_TYPE=Release
 Eg.
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH 10/10] hashmap_for_each_entry(): work around MSVC's run-time check failure #3
  2020-09-25 14:28 [PATCH 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                   ` (8 preceding siblings ...)
  2020-09-25 14:28 ` [PATCH 09/10] cmake (Windows): recommend using Visual Studio's built-in CMake support Johannes Schindelin via GitGitGadget
@ 2020-09-25 14:28 ` Johannes Schindelin via GitGitGadget
  2020-09-25 18:38   ` Junio C Hamano
  2020-09-26 21:32 ` [PATCH v2 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
  10 siblings, 1 reply; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-25 14:28 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

When compiling Git in Visual C, we do not have the luxury of
support for `typeof()`, and therefore `OFFSETOF_VAR()` unfortunately
has to fall back to pointer arithmetic.

When compiling code using the `hashmap_for_each_entry()` macro in Debug
mode, this leads to the "run-time check failure #3" because the variable
passed as `var` are not initialized, yet we calculate the pointer
difference `&(var->member)-var`.

This "run-time check failure" causes a scary dialog to pop up.

Work around this by initializing the respective variables.

Note: according to the C standard, performing pointer arithmetic
with `NULL` is not exactly well-defined, but it seems to work
here, and it is at least better than performing pointer arithmetic
with an uninitialized pointer.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 attr.c                              |  2 +-
 blame.c                             |  4 ++--
 bloom.c                             |  2 +-
 builtin/describe.c                  |  2 +-
 builtin/difftool.c                  |  2 +-
 builtin/fast-import.c               |  2 +-
 builtin/sparse-checkout.c           |  6 +++---
 config.c                            |  2 +-
 merge-recursive.c                   | 10 +++++-----
 name-hash.c                         |  2 +-
 revision.c                          |  4 ++--
 submodule-config.c                  |  2 +-
 t/helper/test-hashmap.c             |  2 +-
 t/helper/test-lazy-init-name-hash.c |  4 ++--
 14 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/attr.c b/attr.c
index a826b2ef1f..b4fde37877 100644
--- a/attr.c
+++ b/attr.c
@@ -160,7 +160,7 @@ static void all_attrs_init(struct attr_hashmap *map, struct attr_check *check)
 	 * field and fill each entry with its corresponding git_attr.
 	 */
 	if (size != check->all_attrs_nr) {
-		struct attr_hash_entry *e;
+		struct attr_hash_entry *e = NULL;
 		struct hashmap_iter iter;
 
 		REALLOC_ARRAY(check->all_attrs, size);
diff --git a/blame.c b/blame.c
index b475bfa1c0..e9879a772e 100644
--- a/blame.c
+++ b/blame.c
@@ -450,7 +450,7 @@ static int fingerprint_similarity(struct fingerprint *a, struct fingerprint *b)
 {
 	int intersection = 0;
 	struct hashmap_iter iter;
-	const struct fingerprint_entry *entry_a, *entry_b;
+	const struct fingerprint_entry *entry_a, *entry_b = NULL;
 
 	hashmap_for_each_entry(&b->map, &iter, entry_b,
 				entry /* member name */) {
@@ -469,7 +469,7 @@ static void fingerprint_subtract(struct fingerprint *a, struct fingerprint *b)
 {
 	struct hashmap_iter iter;
 	struct fingerprint_entry *entry_a;
-	const struct fingerprint_entry *entry_b;
+	const struct fingerprint_entry *entry_b = NULL;
 
 	hashmap_iter_init(&b->map, &iter);
 
diff --git a/bloom.c b/bloom.c
index 1a573226e7..ee45e9ccce 100644
--- a/bloom.c
+++ b/bloom.c
@@ -221,7 +221,7 @@ struct bloom_filter *get_bloom_filter(struct repository *r,
 
 	if (diffopt.num_changes <= max_changes) {
 		struct hashmap pathmap;
-		struct pathmap_hash_entry *e;
+		struct pathmap_hash_entry *e = NULL;
 		struct hashmap_iter iter;
 		hashmap_init(&pathmap, pathmap_cmp, NULL, 0);
 
diff --git a/builtin/describe.c b/builtin/describe.c
index 7668591d57..8b281cf426 100644
--- a/builtin/describe.c
+++ b/builtin/describe.c
@@ -332,7 +332,7 @@ static void describe_commit(struct object_id *oid, struct strbuf *dst)
 	if (!have_util) {
 		struct hashmap_iter iter;
 		struct commit *c;
-		struct commit_name *n;
+		struct commit_name *n = NULL;
 
 		init_commit_names(&commit_names);
 		hashmap_for_each_entry(&names, &iter, n,
diff --git a/builtin/difftool.c b/builtin/difftool.c
index 7ac432b881..a1527ea01c 100644
--- a/builtin/difftool.c
+++ b/builtin/difftool.c
@@ -344,7 +344,7 @@ static int run_dir_diff(const char *extcmd, int symlinks, const char *prefix,
 	FILE *fp;
 	struct hashmap working_tree_dups, submodules, symlinks2;
 	struct hashmap_iter iter;
-	struct pair_entry *entry;
+	struct pair_entry *entry = NULL;
 	struct index_state wtindex;
 	struct checkout lstate, rstate;
 	int rc, flags = RUN_GIT_CMD, err = 0;
diff --git a/builtin/fast-import.c b/builtin/fast-import.c
index 1bf50a73dc..72154383c3 100644
--- a/builtin/fast-import.c
+++ b/builtin/fast-import.c
@@ -498,7 +498,7 @@ static void invalidate_pack_id(unsigned int id)
 	unsigned long lu;
 	struct tag *t;
 	struct hashmap_iter iter;
-	struct object_entry *e;
+	struct object_entry *e = NULL;
 
 	hashmap_for_each_entry(&object_table, &iter, e, ent) {
 		if (e->pack_id == id)
diff --git a/builtin/sparse-checkout.c b/builtin/sparse-checkout.c
index 4003f4d13a..fcd87da036 100644
--- a/builtin/sparse-checkout.c
+++ b/builtin/sparse-checkout.c
@@ -67,7 +67,7 @@ static int sparse_checkout_list(int argc, const char **argv)
 
 	if (pl.use_cone_patterns) {
 		int i;
-		struct pattern_entry *pe;
+		struct pattern_entry *pe = NULL;
 		struct hashmap_iter iter;
 		struct string_list sl = STRING_LIST_INIT_DUP;
 
@@ -153,7 +153,7 @@ static char *escaped_pattern(char *pattern)
 static void write_cone_to_file(FILE *fp, struct pattern_list *pl)
 {
 	int i;
-	struct pattern_entry *pe;
+	struct pattern_entry *pe = NULL;
 	struct hashmap_iter iter;
 	struct string_list sl = STRING_LIST_INIT_DUP;
 	struct strbuf parent_pattern = STRBUF_INIT;
@@ -465,7 +465,7 @@ static void add_patterns_cone_mode(int argc, const char **argv,
 				   struct pattern_list *pl)
 {
 	struct strbuf buffer = STRBUF_INIT;
-	struct pattern_entry *pe;
+	struct pattern_entry *pe = NULL;
 	struct hashmap_iter iter;
 	struct pattern_list existing;
 	char *sparse_filename = get_sparse_checkout_filename();
diff --git a/config.c b/config.c
index 2bdff4457b..83c72dd6e6 100644
--- a/config.c
+++ b/config.c
@@ -1953,7 +1953,7 @@ void git_configset_init(struct config_set *cs)
 
 void git_configset_clear(struct config_set *cs)
 {
-	struct config_set_element *entry;
+	struct config_set_element *entry = NULL;
 	struct hashmap_iter iter;
 	if (!cs->hash_initialized)
 		return;
diff --git a/merge-recursive.c b/merge-recursive.c
index d0214335a7..11ea550b0d 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -2151,8 +2151,8 @@ static void handle_directory_level_conflicts(struct merge_options *opt,
 					     struct tree *merge)
 {
 	struct hashmap_iter iter;
-	struct dir_rename_entry *head_ent;
-	struct dir_rename_entry *merge_ent;
+	struct dir_rename_entry *head_ent = NULL;
+	struct dir_rename_entry *merge_ent = NULL;
 
 	struct string_list remove_from_head = STRING_LIST_INIT_NODUP;
 	struct string_list remove_from_merge = STRING_LIST_INIT_NODUP;
@@ -2221,7 +2221,7 @@ static struct hashmap *get_directory_renames(struct diff_queue_struct *pairs)
 {
 	struct hashmap *dir_renames;
 	struct hashmap_iter iter;
-	struct dir_rename_entry *entry;
+	struct dir_rename_entry *entry = NULL;
 	int i;
 
 	/*
@@ -2590,7 +2590,7 @@ static struct string_list *get_renames(struct merge_options *opt,
 	int i;
 	struct hashmap collisions;
 	struct hashmap_iter iter;
-	struct collision_entry *e;
+	struct collision_entry *e = NULL;
 	struct string_list *renames;
 
 	compute_collisions(&collisions, dir_renames, pairs);
@@ -2862,7 +2862,7 @@ static void initial_cleanup_rename(struct diff_queue_struct *pairs,
 				   struct hashmap *dir_renames)
 {
 	struct hashmap_iter iter;
-	struct dir_rename_entry *e;
+	struct dir_rename_entry *e = NULL;
 
 	hashmap_for_each_entry(dir_renames, &iter, e,
 				ent /* member name */) {
diff --git a/name-hash.c b/name-hash.c
index fb526a3775..a3f710b2f8 100644
--- a/name-hash.c
+++ b/name-hash.c
@@ -706,7 +706,7 @@ void adjust_dirname_case(struct index_state *istate, char *name)
 
 struct cache_entry *index_file_exists(struct index_state *istate, const char *name, int namelen, int icase)
 {
-	struct cache_entry *ce;
+	struct cache_entry *ce = NULL;
 	unsigned int hash = memihash(name, namelen);
 
 	lazy_init_name_hash(istate);
diff --git a/revision.c b/revision.c
index 067030e64c..232de3f6f5 100644
--- a/revision.c
+++ b/revision.c
@@ -132,7 +132,7 @@ static void paths_and_oids_init(struct hashmap *map)
 static void paths_and_oids_clear(struct hashmap *map)
 {
 	struct hashmap_iter iter;
-	struct path_and_oids_entry *entry;
+	struct path_and_oids_entry *entry = NULL;
 
 	hashmap_for_each_entry(map, &iter, entry, ent /* member name */) {
 		oidset_clear(&entry->trees);
@@ -215,7 +215,7 @@ void mark_trees_uninteresting_sparse(struct repository *r,
 	unsigned has_interesting = 0, has_uninteresting = 0;
 	struct hashmap map;
 	struct hashmap_iter map_iter;
-	struct path_and_oids_entry *entry;
+	struct path_and_oids_entry *entry = NULL;
 	struct object_id *oid;
 	struct oidset_iter iter;
 
diff --git a/submodule-config.c b/submodule-config.c
index c569e22aa3..662b9d9c09 100644
--- a/submodule-config.c
+++ b/submodule-config.c
@@ -89,7 +89,7 @@ static void free_one_config(struct submodule_entry *entry)
 static void submodule_cache_clear(struct submodule_cache *cache)
 {
 	struct hashmap_iter iter;
-	struct submodule_entry *entry;
+	struct submodule_entry *entry = NULL;
 
 	if (!cache->initialized)
 		return;
diff --git a/t/helper/test-hashmap.c b/t/helper/test-hashmap.c
index f38706216f..2bde90309b 100644
--- a/t/helper/test-hashmap.c
+++ b/t/helper/test-hashmap.c
@@ -162,7 +162,7 @@ int cmd__hashmap(int argc, const char **argv)
 	while (strbuf_getline(&line, stdin) != EOF) {
 		char *cmd, *p1 = NULL, *p2 = NULL;
 		unsigned int hash = 0;
-		struct test_entry *entry;
+		struct test_entry *entry = NULL;
 
 		/* break line into command and up to two parameters */
 		cmd = strtok(line.buf, DELIM);
diff --git a/t/helper/test-lazy-init-name-hash.c b/t/helper/test-lazy-init-name-hash.c
index cd1b4c9736..2cb1fa3d8c 100644
--- a/t/helper/test-lazy-init-name-hash.c
+++ b/t/helper/test-lazy-init-name-hash.c
@@ -29,8 +29,8 @@ static void dump_run(void)
 		char name[FLEX_ARRAY];
 	};
 
-	struct dir_entry *dir;
-	struct cache_entry *ce;
+	struct dir_entry *dir = NULL;
+	struct cache_entry *ce = NULL;
 
 	read_cache();
 	if (single) {
-- 
gitgitgadget

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [PATCH 02/10] cmake: do find Git for Windows' shell interpreter
  2020-09-25 14:28 ` [PATCH 02/10] cmake: do find Git for Windows' shell interpreter Johannes Schindelin via GitGitGadget
@ 2020-09-25 16:25   ` Sibi Siddharthan
  2020-09-26 20:32     ` Johannes Schindelin
  0 siblings, 1 reply; 70+ messages in thread
From: Sibi Siddharthan @ 2020-09-25 16:25 UTC (permalink / raw)
  To: Johannes Schindelin via GitGitGadget
  Cc: git, Đoàn Trần Công Danh, SZEDER Gábor,
	Johannes Schindelin

> diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
> index 5007f173f1..d14fa4f3dc 100644
> --- a/contrib/buildsystems/CMakeLists.txt
> +++ b/contrib/buildsystems/CMakeLists.txt
> @@ -43,8 +43,11 @@ set(CMAKE_SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/../..)
>
>  find_program(SH_EXE sh)
>  if(NOT SH_EXE)
> -       message(FATAL_ERROR "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/")
> +       set(SH_EXE "C:/Program Files/Git/bin/sh.exe")
> +       if(NOT EXISTS ${SH_EXE})
> +               message(FATAL_ERROR "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/")
> +       endif()
>  endif()
>
Let's not point SH_EXE to the 'program files' directory.
find_program() searches 'PATH' for sh.
Since the Git-for-windows installer does append
'your_installation_directory'/Git/bin to the PATH variable, it should
be fine.

I personally don't install my dev tools(except Visual Studio) to
Program Files(because of the _space_), it messes up the Makefiles.

Thank You,
Sibi Siddharthan

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [PATCH 07/10] cmake (Windows): complain when encountering an unknown compiler
  2020-09-25 14:28 ` [PATCH 07/10] cmake (Windows): complain when encountering an unknown compiler Johannes Schindelin via GitGitGadget
@ 2020-09-25 17:29   ` Sibi Siddharthan
  2020-09-26 20:33     ` Johannes Schindelin
  0 siblings, 1 reply; 70+ messages in thread
From: Sibi Siddharthan @ 2020-09-25 17:29 UTC (permalink / raw)
  To: Johannes Schindelin via GitGitGadget
  Cc: git, Đoàn Trần Công Danh, SZEDER Gábor,
	Johannes Schindelin

On Fri, Sep 25, 2020 at 7:58 PM Johannes Schindelin via GitGitGadget
<gitgitgadget@gmail.com> wrote:
>
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> We have some custom handling regarding the link options, which are
> specific to each compiler.
>
> Therefore: let's not just continue without setting the link options when
> configuring for a currently unhandled compiler, but error out.
>
> Note: for some reason, the `invalidcontinue.obj` trick seems not to work
> in this developer's hands when building Git in Debug mode: the assertion
> dialog that is supposed to be suppressed still pops up, complaining
> about the `entry` variable being uninitialized when it is used in
> `config.c`'s line 1961.

Does this happen when running Git under the Visual Studio debugger?
If so this might help
_CrtSetReportMode(_CRT_ASSERT,0);

After digging a bit more I found out that _CRTDBG_MODE_DEBUG is
environment sensitive.
It depends on how the debugger handles DbgPrintEx().

Thank You,
Sibi Siddharthan

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [PATCH 09/10] cmake (Windows): recommend using Visual Studio's built-in CMake support
  2020-09-25 14:28 ` [PATCH 09/10] cmake (Windows): recommend using Visual Studio's built-in CMake support Johannes Schindelin via GitGitGadget
@ 2020-09-25 18:22   ` Junio C Hamano
  2020-09-26 20:45     ` Johannes Schindelin
  0 siblings, 1 reply; 70+ messages in thread
From: Junio C Hamano @ 2020-09-25 18:22 UTC (permalink / raw)
  To: Johannes Schindelin via GitGitGadget
  Cc: git, Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Johannes Schindelin

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> It is a lot more convenient to use than having to specify the
> configuration in CMake manually (does not matter whether using the
> command-line or CMake's GUI).
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>  contrib/buildsystems/CMakeLists.txt | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
> index 1eaeb8b8e0..442b4e69ad 100644
> --- a/contrib/buildsystems/CMakeLists.txt
> +++ b/contrib/buildsystems/CMakeLists.txt
> @@ -4,7 +4,17 @@
>  
>  #[[
>  
> -Instructions to run CMake:
> +Instructions how to use this in Visual Studio:
> +
> +Open the worktree as a folder. Visual Studio 2019 and later will detect
> +the CMake configuration automatically and set everything up for you,
> +ready to build. You can then run the tests in `t/` via a regular Git Bash.
> +
> +Note: Visual Studio also has the option of opening the CMake configuration
> +directly; Using this option, Visual Studio will not find the source code,
> +though, therefore the `File>Open>Folder...` option is preferred.
> +
> +Instructions to run CMake manually:
>  
>  cmake `relative-path-to-CMakeLists.txt` -DCMAKE_BUILD_TYPE=Release
>  Eg.

Having the primary case upfront is a good idea.  As we discussed,
our source tree structure (especially the .gitignore we ship) only
supports an separate-dir build in contrib/buildsystems/out, so we
should update the "manually" part of the instruction to guide users
to use the same location.  Perhaps something along the line of the
attached.

Also, after the post-context of the attached patch, there are
mentions of Visual Studio.  Please double check if they need
adjustment, or more preferrably the above paragraph the patch in
question added is all that is needed by Visual Studio users, in
which case perhaps it would be a good idea to remove all mention of
Visual Studio there to avoid sending confusing choices to the
readers.

Thanks.

 contrib/buildsystems/CMakeLists.txt | 16 +++++++---------
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index 442b4e69ad..0c748949f9 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -16,15 +16,13 @@ though, therefore the `File>Open>Folder...` option is preferred.
 
 Instructions to run CMake manually:
 
-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
-
-For out of source builds, say build in 'git/git-build/'
-	`mkdir git-build;cd git-build; cmake ../contrib/buildsystems/`
-This will build the git binaries in git-build directory
+    mkdir -p contrib/buildsystems/out
+    cd contrib/buildsystems/out
+    cmake ../ -DCMAKE_BUILD_TYPE=Release
+
+This will build the git binaries in contrib/buildsystems/out
+directory (our top-level .gitignore file knows to ignore contents of
+this directory).
 
 Possible build configurations(-DCMAKE_BUILD_TYPE) with corresponding
 compiler flags

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [PATCH 10/10] hashmap_for_each_entry(): work around MSVC's run-time check failure #3
  2020-09-25 14:28 ` [PATCH 10/10] hashmap_for_each_entry(): work around MSVC's run-time check failure #3 Johannes Schindelin via GitGitGadget
@ 2020-09-25 18:38   ` Junio C Hamano
  2020-09-26 16:54     ` Junio C Hamano
  0 siblings, 1 reply; 70+ messages in thread
From: Junio C Hamano @ 2020-09-25 18:38 UTC (permalink / raw)
  To: Johannes Schindelin via GitGitGadget
  Cc: git, Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Johannes Schindelin

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> When compiling Git in Visual C, we do not have the luxury of
> support for `typeof()`, and therefore `OFFSETOF_VAR()` unfortunately
> has to fall back to pointer arithmetic.

Sigh.

Short of changing the signature of hashmap_put_entry() and friends
to also take the type of these variables, I do not see any kosher
way to reimplement the users of OFFSETOF_VAR() to help compilers
without typeof() offhand.  As a one-time annotation, the unfortunate
noise we see in this patch may be tolerable, but what may make this
approach unsustainable is that average programmers would not know,
without compiling with that particular compiler, if their new
variable that points at a hash_entry needs to have an oterwise
unnecessary initialization.  Also the variables that are left
uninitialized by this patch may later require such an initialization.

Of course, it does not help that this workaround relies on an
undefined behaviour, as you pointed out.

> When compiling code using the `hashmap_for_each_entry()` macro in Debug
> mode, this leads to the "run-time check failure #3" because the variable
> passed as `var` are not initialized, yet we calculate the pointer
> difference `&(var->member)-var`.

Whoa, wait.  If it is just that macro, can we perhaps do something
like the attached patch?

>
> This "run-time check failure" causes a scary dialog to pop up.
>
> Work around this by initializing the respective variables.
>
> Note: according to the C standard, performing pointer arithmetic
> with `NULL` is not exactly well-defined, but it seems to work
> here, and it is at least better than performing pointer arithmetic
> with an uninitialized pointer.

 hashmap.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hashmap.h b/hashmap.h
index ef220de4c6..49cd8a8e92 100644
--- a/hashmap.h
+++ b/hashmap.h
@@ -449,7 +449,7 @@ static inline struct hashmap_entry *hashmap_iter_first(struct hashmap *map,
  * containing a @member which is a "struct hashmap_entry"
  */
 #define hashmap_for_each_entry(map, iter, var, member) \
-	for (var = hashmap_iter_first_entry_offset(map, iter, \
+	for (var = NULL, var = hashmap_iter_first_entry_offset(map, iter, \
 						OFFSETOF_VAR(var, member)); \
 		var; \
 		var = hashmap_iter_next_entry_offset(iter, \

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [PATCH 06/10] cmake (Windows): let the `.dll` files are found when running the tests
  2020-09-25 14:28 ` [PATCH 06/10] cmake (Windows): let the `.dll` files are found when running the tests Johannes Schindelin via GitGitGadget
@ 2020-09-25 19:48   ` Eric Sunshine
  2020-09-26 21:00     ` Johannes Schindelin
  0 siblings, 1 reply; 70+ messages in thread
From: Eric Sunshine @ 2020-09-25 19:48 UTC (permalink / raw)
  To: Johannes Schindelin via GitGitGadget
  Cc: Git List, Sibi Siddharthan,
	Đoàn Trần Công Danh, SZEDER Gábor,
	Johannes Schindelin

On Fri, Sep 25, 2020 at 10:28 AM Johannes Schindelin via GitGitGadget
<gitgitgadget@gmail.com> wrote:
> cmake (Windows): let the `.dll` files are found when running the tests

I'm having trouble parsing this. Maybe you want s/let/ensure/ ?

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [PATCH 10/10] hashmap_for_each_entry(): work around MSVC's run-time check failure #3
  2020-09-25 18:38   ` Junio C Hamano
@ 2020-09-26 16:54     ` Junio C Hamano
  2020-09-26 20:57       ` Johannes Schindelin
  0 siblings, 1 reply; 70+ messages in thread
From: Junio C Hamano @ 2020-09-26 16:54 UTC (permalink / raw)
  To: Johannes Schindelin via GitGitGadget
  Cc: git, Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Johannes Schindelin

Junio C Hamano <gitster@pobox.com> writes:

> Whoa, wait.  If it is just that macro, can we perhaps do something
> like the attached patch?

I looked at all the uses of OFFSETOF_VAR() and I think the one used
for hashmap_for_each_entry() is the only instance that 'var' given
to it can legitimately be uninitialized, if typeof() were available.

Here are the findings.

#define hashmap_put_entry(map, keyvar, member) \
	container_of_or_null_offset(hashmap_put(map, &(keyvar)->member), \
				OFFSETOF_VAR(keyvar, member))

The keyvar is a pointer to the entry being placed in the map; it
must hold a valid one so the pointer-diff implementation of
OFFSETOF_VAR() should work fine, or we are putting garbage in to the
map.

#define hashmap_remove_entry(map, keyvar, member, keydata) \
	container_of_or_null_offset( \
			hashmap_remove(map, &(keyvar)->member, keydata), \
			OFFSETOF_VAR(keyvar, member))

The keyvar is used to match against an existing entry in the map to
be removed---it must have a valid value.

#define hashmap_for_each_entry(map, iter, var, member) \
	for (var = hashmap_iter_first_entry_offset(map, iter, \
						OFFSETOF_VAR(var, member)); \
		var; \
		var = hashmap_iter_next_entry_offset(iter, \
						OFFSETOF_VAR(var, member)))

This, as you discovered, can be fed an uninitialized var and the
first thing it does is to use OFFSETOF_VAR() on it in order to call
hashmap_iter_first_entry_offset().  After that, i.e. when we called
that function to start the loop, var is defined and we would be OK.

The trick I suggested is to initialize var to NULL before making the
call to hashmap_iter_first_entry_offset(), i.e.

	for (var = NULL, \
	     var = hashmap_iter_first_entry_offset(map, iter, \
						OFFSETOF_VAR(var, member)); \

#define hashmap_get_entry(map, keyvar, member, keydata) \
	container_of_or_null_offset( \
				hashmap_get(map, &(keyvar)->member, keydata), \
				OFFSETOF_VAR(keyvar, member))

Must be OK for the same reason _put_entry() is OK.

#define hashmap_get_next_entry(map, var, member) \
	container_of_or_null_offset(hashmap_get_next(map, &(var)->member), \
				OFFSETOF_VAR(var, member))

This tries to go to the next-equal-pointer starting from var, so var
must be valid already.

So, perhaps the attached may be a viable replacement that would be
more futureproof with less maintenance cost, I suspect.

Thanks.

--- >8 ----- cut here ----- >8 ---
Subject: hashmap_for_each_entry(): workaround MSVC's runtime check failure #3

The OFFSETOF_VAR(var, member) macro is implemented in terms of
offsetof(typeof(*var), member) with compilers that know typeof(),
but its fallback implemenation compares &(var->member) and (var) and
count the distance in bytes, i.e.

    ((uintptr_t)&(var)->member - (uintptr_t)(var))

MSVC's runtime check, when fed an uninitialized 'var', flags this as
a use of an uninitialized variable (and that is legit---uninitialized
contents of 'var' is subtracted) in a debug build.

After auditing all 6 uses of OFFSETOF_VAR(), 1 of them does feed a
potentially uninitialized 'var' to the macro in the beginning of the
for() loop:

    #define hashmap_for_each_entry(map, iter, var, member) \
            for (var = hashmap_iter_first_entry_offset(map, iter, \
                                                    OFFSETOF_VAR(var, member)); \
                    var; \
                    var = hashmap_iter_next_entry_offset(iter, \
                                                    OFFSETOF_VAR(var, member)))

We can work around this by making sure that var has _some_ value
when OFFSETOF_VAR() is called.  Strictly speaking, it invites
undefined behaviour to use NULL here if we end up with pointer
comparison, but MSVC runtime seems to be happy with it, and most
other systems have typeof() and don't even need pointer comparison
fallback code.

---
 hashmap.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git c/hashmap.h w/hashmap.h
index ef220de4c6..b011b394fe 100644
--- c/hashmap.h
+++ w/hashmap.h
@@ -449,7 +449,8 @@ static inline struct hashmap_entry *hashmap_iter_first(struct hashmap *map,
  * containing a @member which is a "struct hashmap_entry"
  */
 #define hashmap_for_each_entry(map, iter, var, member) \
-	for (var = hashmap_iter_first_entry_offset(map, iter, \
+	for (var = NULL, /* for systems without typeof */ \
+	     var = hashmap_iter_first_entry_offset(map, iter, \
 						OFFSETOF_VAR(var, member)); \
 		var; \
 		var = hashmap_iter_next_entry_offset(iter, \

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [PATCH 02/10] cmake: do find Git for Windows' shell interpreter
  2020-09-25 16:25   ` Sibi Siddharthan
@ 2020-09-26 20:32     ` Johannes Schindelin
  2020-09-27  2:25       ` Đoàn Trần Công Danh
  0 siblings, 1 reply; 70+ messages in thread
From: Johannes Schindelin @ 2020-09-26 20:32 UTC (permalink / raw)
  To: Sibi Siddharthan
  Cc: Johannes Schindelin via GitGitGadget, git,
	Đoàn Trần Công Danh, SZEDER Gábor

Hi Sibi,

On Fri, 25 Sep 2020, Sibi Siddharthan wrote:

> > diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
> > index 5007f173f1..d14fa4f3dc 100644
> > --- a/contrib/buildsystems/CMakeLists.txt
> > +++ b/contrib/buildsystems/CMakeLists.txt
> > @@ -43,8 +43,11 @@ set(CMAKE_SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/../..)
> >
> >  find_program(SH_EXE sh)
> >  if(NOT SH_EXE)
> > -       message(FATAL_ERROR "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/")
> > +       set(SH_EXE "C:/Program Files/Git/bin/sh.exe")
> > +       if(NOT EXISTS ${SH_EXE})
> > +               message(FATAL_ERROR "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/")
> > +       endif()
> >  endif()
> >
> Let's not point SH_EXE to the 'program files' directory.

It is not doing that, except as a fall-back in case the `sh` program
was not found in the `PATH`.

> find_program() searches 'PATH' for sh.

Right.

> Since the Git-for-windows installer does append
> 'your_installation_directory'/Git/bin to the PATH variable, it should
> be fine.

No, it does not. Quite purposefully so.

The `/bin/` directory is kind of a hack to reinstate _some_ level of
support for use cases that relied on Git for Windows v1.x installing its
binaries into that directory (v2.x distributes them between `/usr/bin/`
and `/mingw64/bin/`).

What _does_ get appended, at least by default, is the `/cmd/` directory
(which does _not_ contain `sh.exe`).

Now, there _is_ an option in the Git for Windows installer to append all
of its Unix tools to the `PATH`, but it is highly discouraged to do so.

> I personally don't install my dev tools(except Visual Studio) to
> Program Files(because of the _space_), it messes up the Makefiles.

Sure, and that's your prerogative. There's unfortunately no good way to
support your use case.

Luckily, the vast majority of Git for Windows' users do not change the
default location, and this patch is for them. (And "them" in this case
includes me, personally ;-))

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [PATCH 07/10] cmake (Windows): complain when encountering an unknown compiler
  2020-09-25 17:29   ` Sibi Siddharthan
@ 2020-09-26 20:33     ` Johannes Schindelin
  0 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin @ 2020-09-26 20:33 UTC (permalink / raw)
  To: Sibi Siddharthan
  Cc: Johannes Schindelin via GitGitGadget, git,
	Đoàn Trần Công Danh, SZEDER Gábor

Hi Sibi,

On Fri, 25 Sep 2020, Sibi Siddharthan wrote:

> On Fri, Sep 25, 2020 at 7:58 PM Johannes Schindelin via GitGitGadget
> <gitgitgadget@gmail.com> wrote:
> >
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > We have some custom handling regarding the link options, which are
> > specific to each compiler.
> >
> > Therefore: let's not just continue without setting the link options when
> > configuring for a currently unhandled compiler, but error out.
> >
> > Note: for some reason, the `invalidcontinue.obj` trick seems not to work
> > in this developer's hands when building Git in Debug mode: the assertion
> > dialog that is supposed to be suppressed still pops up, complaining
> > about the `entry` variable being uninitialized when it is used in
> > `config.c`'s line 1961.
>
> Does this happen when running Git under the Visual Studio debugger?

Whoops. I meant to remove this paragraph after addressing that `run-time
check failure #3` problem.

Will remove it before sending the next iteration.

Thanks,
Dscho

> If so this might help
> _CrtSetReportMode(_CRT_ASSERT,0);
>
> After digging a bit more I found out that _CRTDBG_MODE_DEBUG is
> environment sensitive.
> It depends on how the debugger handles DbgPrintEx().
>
> Thank You,
> Sibi Siddharthan
>
>

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [PATCH 09/10] cmake (Windows): recommend using Visual Studio's built-in CMake support
  2020-09-25 18:22   ` Junio C Hamano
@ 2020-09-26 20:45     ` Johannes Schindelin
  0 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin @ 2020-09-26 20:45 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: Johannes Schindelin via GitGitGadget, git, Sibi Siddharthan,
	Đoàn Trần Công Danh, SZEDER Gábor

Hi Junio,

On Fri, 25 Sep 2020, Junio C Hamano wrote:

> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
>
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > It is a lot more convenient to use than having to specify the
> > configuration in CMake manually (does not matter whether using the
> > command-line or CMake's GUI).
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >  contrib/buildsystems/CMakeLists.txt | 12 +++++++++++-
> >  1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
> > index 1eaeb8b8e0..442b4e69ad 100644
> > --- a/contrib/buildsystems/CMakeLists.txt
> > +++ b/contrib/buildsystems/CMakeLists.txt
> > @@ -4,7 +4,17 @@
> >
> >  #[[
> >
> > -Instructions to run CMake:
> > +Instructions how to use this in Visual Studio:
> > +
> > +Open the worktree as a folder. Visual Studio 2019 and later will detect
> > +the CMake configuration automatically and set everything up for you,
> > +ready to build. You can then run the tests in `t/` via a regular Git Bash.
> > +
> > +Note: Visual Studio also has the option of opening the CMake configuration
> > +directly; Using this option, Visual Studio will not find the source code,
> > +though, therefore the `File>Open>Folder...` option is preferred.
> > +
> > +Instructions to run CMake manually:
> >
> >  cmake `relative-path-to-CMakeLists.txt` -DCMAKE_BUILD_TYPE=Release
> >  Eg.
>
> Having the primary case upfront is a good idea.  As we discussed,
> our source tree structure (especially the .gitignore we ship) only
> supports an separate-dir build in contrib/buildsystems/out, so we
> should update the "manually" part of the instruction to guide users
> to use the same location.  Perhaps something along the line of the
> attached.

I squashed your changes into the patch.

> Also, after the post-context of the attached patch, there are
> mentions of Visual Studio.  Please double check if they need
> adjustment, or more preferrably the above paragraph the patch in
> question added is all that is needed by Visual Studio users, in
> which case perhaps it would be a good idea to remove all mention of
> Visual Studio there to avoid sending confusing choices to the
> readers.

The parts that still mention Visual Studio are in the part that talks
about running CMake manually, in which case they strike me as helpful,
still.

Thank you,
Dscho

>
> Thanks.
>
>  contrib/buildsystems/CMakeLists.txt | 16 +++++++---------
>  1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
> index 442b4e69ad..0c748949f9 100644
> --- a/contrib/buildsystems/CMakeLists.txt
> +++ b/contrib/buildsystems/CMakeLists.txt
> @@ -16,15 +16,13 @@ though, therefore the `File>Open>Folder...` option is preferred.
>
>  Instructions to run CMake manually:
>
> -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
> -
> -For out of source builds, say build in 'git/git-build/'
> -	`mkdir git-build;cd git-build; cmake ../contrib/buildsystems/`
> -This will build the git binaries in git-build directory
> +    mkdir -p contrib/buildsystems/out
> +    cd contrib/buildsystems/out
> +    cmake ../ -DCMAKE_BUILD_TYPE=Release
> +
> +This will build the git binaries in contrib/buildsystems/out
> +directory (our top-level .gitignore file knows to ignore contents of
> +this directory).
>
>  Possible build configurations(-DCMAKE_BUILD_TYPE) with corresponding
>  compiler flags
>
>

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [PATCH 10/10] hashmap_for_each_entry(): work around MSVC's run-time check failure #3
  2020-09-26 16:54     ` Junio C Hamano
@ 2020-09-26 20:57       ` Johannes Schindelin
  0 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin @ 2020-09-26 20:57 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: Johannes Schindelin via GitGitGadget, git, Sibi Siddharthan,
	Đoàn Trần Công Danh, SZEDER Gábor

Hi Junio,

On Sat, 26 Sep 2020, Junio C Hamano wrote:

> Junio C Hamano <gitster@pobox.com> writes:
>
> > Whoa, wait.  If it is just that macro, can we perhaps do something
> > like the attached patch?
>
> I looked at all the uses of OFFSETOF_VAR() and I think the one used
> for hashmap_for_each_entry() is the only instance that 'var' given
> to it can legitimately be uninitialized, if typeof() were available.

Thank you for doing all that leg work. TBH I didn't even think about
looking further, after having run a couple tests manually that I thought
were exhaustive in exercising this type of code pattern.

> Here are the findings.
>
> #define hashmap_put_entry(map, keyvar, member) \
> 	container_of_or_null_offset(hashmap_put(map, &(keyvar)->member), \
> 				OFFSETOF_VAR(keyvar, member))
>
> The keyvar is a pointer to the entry being placed in the map; it
> must hold a valid one so the pointer-diff implementation of
> OFFSETOF_VAR() should work fine, or we are putting garbage in to the
> map.
>
> #define hashmap_remove_entry(map, keyvar, member, keydata) \
> 	container_of_or_null_offset( \
> 			hashmap_remove(map, &(keyvar)->member, keydata), \
> 			OFFSETOF_VAR(keyvar, member))
>
> The keyvar is used to match against an existing entry in the map to
> be removed---it must have a valid value.
>
> #define hashmap_for_each_entry(map, iter, var, member) \
> 	for (var = hashmap_iter_first_entry_offset(map, iter, \
> 						OFFSETOF_VAR(var, member)); \
> 		var; \
> 		var = hashmap_iter_next_entry_offset(iter, \
> 						OFFSETOF_VAR(var, member)))
>
> This, as you discovered, can be fed an uninitialized var and the
> first thing it does is to use OFFSETOF_VAR() on it in order to call
> hashmap_iter_first_entry_offset().  After that, i.e. when we called
> that function to start the loop, var is defined and we would be OK.
>
> The trick I suggested is to initialize var to NULL before making the
> call to hashmap_iter_first_entry_offset(), i.e.
>
> 	for (var = NULL, \
> 	     var = hashmap_iter_first_entry_offset(map, iter, \
> 						OFFSETOF_VAR(var, member)); \
>
> #define hashmap_get_entry(map, keyvar, member, keydata) \
> 	container_of_or_null_offset( \
> 				hashmap_get(map, &(keyvar)->member, keydata), \
> 				OFFSETOF_VAR(keyvar, member))
>
> Must be OK for the same reason _put_entry() is OK.
>
> #define hashmap_get_next_entry(map, var, member) \
> 	container_of_or_null_offset(hashmap_get_next(map, &(var)->member), \
> 				OFFSETOF_VAR(var, member))
>
> This tries to go to the next-equal-pointer starting from var, so var
> must be valid already.
>
> So, perhaps the attached may be a viable replacement that would be
> more futureproof with less maintenance cost, I suspect.

Definitely much nicer to maintain, and easier to verify. In my hands, this
works better than my manual touch-ups of _all_ the call sites. So I
replaced my patch with yours (adding your SOB).

Ciao,
Dscho

> Thanks.
>
> --- >8 ----- cut here ----- >8 ---
> Subject: hashmap_for_each_entry(): workaround MSVC's runtime check failure #3
>
> The OFFSETOF_VAR(var, member) macro is implemented in terms of
> offsetof(typeof(*var), member) with compilers that know typeof(),
> but its fallback implemenation compares &(var->member) and (var) and
> count the distance in bytes, i.e.
>
>     ((uintptr_t)&(var)->member - (uintptr_t)(var))
>
> MSVC's runtime check, when fed an uninitialized 'var', flags this as
> a use of an uninitialized variable (and that is legit---uninitialized
> contents of 'var' is subtracted) in a debug build.
>
> After auditing all 6 uses of OFFSETOF_VAR(), 1 of them does feed a
> potentially uninitialized 'var' to the macro in the beginning of the
> for() loop:
>
>     #define hashmap_for_each_entry(map, iter, var, member) \
>             for (var = hashmap_iter_first_entry_offset(map, iter, \
>                                                     OFFSETOF_VAR(var, member)); \
>                     var; \
>                     var = hashmap_iter_next_entry_offset(iter, \
>                                                     OFFSETOF_VAR(var, member)))
>
> We can work around this by making sure that var has _some_ value
> when OFFSETOF_VAR() is called.  Strictly speaking, it invites
> undefined behaviour to use NULL here if we end up with pointer
> comparison, but MSVC runtime seems to be happy with it, and most
> other systems have typeof() and don't even need pointer comparison
> fallback code.
>
> ---
>  hashmap.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git c/hashmap.h w/hashmap.h
> index ef220de4c6..b011b394fe 100644
> --- c/hashmap.h
> +++ w/hashmap.h
> @@ -449,7 +449,8 @@ static inline struct hashmap_entry *hashmap_iter_first(struct hashmap *map,
>   * containing a @member which is a "struct hashmap_entry"
>   */
>  #define hashmap_for_each_entry(map, iter, var, member) \
> -	for (var = hashmap_iter_first_entry_offset(map, iter, \
> +	for (var = NULL, /* for systems without typeof */ \
> +	     var = hashmap_iter_first_entry_offset(map, iter, \
>  						OFFSETOF_VAR(var, member)); \
>  		var; \
>  		var = hashmap_iter_next_entry_offset(iter, \
>
>

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [PATCH 06/10] cmake (Windows): let the `.dll` files are found when running the tests
  2020-09-25 19:48   ` Eric Sunshine
@ 2020-09-26 21:00     ` Johannes Schindelin
  0 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin @ 2020-09-26 21:00 UTC (permalink / raw)
  To: Eric Sunshine
  Cc: Johannes Schindelin via GitGitGadget, Git List, Sibi Siddharthan,
	Đoàn Trần Công Danh, SZEDER Gábor

Hi Eric,

On Fri, 25 Sep 2020, Eric Sunshine wrote:

> On Fri, Sep 25, 2020 at 10:28 AM Johannes Schindelin via GitGitGadget
> <gitgitgadget@gmail.com> wrote:
> > cmake (Windows): let the `.dll` files are found when running the tests
>
> I'm having trouble parsing this. Maybe you want s/let/ensure/ ?

Right, that does not parse at all. I did `s/are/be/` instead.

Thanks,
Dscho

^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v2 00/10] CMake and Visual Studio
  2020-09-25 14:28 [PATCH 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                   ` (9 preceding siblings ...)
  2020-09-25 14:28 ` [PATCH 10/10] hashmap_for_each_entry(): work around MSVC's run-time check failure #3 Johannes Schindelin via GitGitGadget
@ 2020-09-26 21:32 ` Johannes Schindelin via GitGitGadget
  2020-09-26 21:32   ` [PATCH v2 01/10] cmake: ignore files generated by CMake as run in " Johannes Schindelin via GitGitGadget
                     ` (10 more replies)
  10 siblings, 11 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-26 21:32 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Johannes Schindelin

The intention of this patch series is to make it as easy as possible for a
Visual Studio user to start building Git from scratch. The idea is to

 * clone Git's source code,
 * open it in Visual Studio via File>Open>Folder...
 * let CMake configure things (and vcpkg build the dependencies, which will
   take a while), and
 * start the build.

It does require a Git for Windows to be installed (so that the source can be
cloned, but also to run the shell script parts of the CMake configuration),
and also to run the tests.

This patch series replaces the patch "Ignore files generated by CMake" I
sent via https://github.com/gitgitgadget/git/pull/735.

Changes since v1:

 * Touched up a couple commit messages in response to reviewer comments
 * Adjusted the instructions at the top of CMakeLists.txt so that the part
   talking about running CMake manually also talks about using 
   contrib/buildsystems/out/ as build directory (in line with the part
   talking about Visual Studio's out-of-the-box experience)
 * Replaced patch 10/10 with Junio's much more elegant solution of editing
   the hashmap_for_each_entry() macro instead of all of its callers.

Johannes Schindelin (9):
  cmake: ignore files generated by CMake as run in Visual Studio
  cmake: do find Git for Windows' shell interpreter
  cmake: ensure that the `vcpkg` packages are found on Windows
  cmake: fall back to using `vcpkg`'s `msgfmt.exe` on Windows
  cmake: quote the path accurately when editing `test-lib.sh`
  cmake (Windows): let the `.dll` files be found when running the tests
  cmake (Windows): complain when encountering an unknown compiler
  cmake (Windows): initialize vcpkg/build dependencies automatically
  cmake (Windows): recommend using Visual Studio's built-in CMake
    support

Junio C Hamano (1):
  hashmap_for_each_entry(): workaround MSVC's runtime check failure #3

 .gitignore                          |  1 +
 contrib/buildsystems/CMakeLists.txt | 57 ++++++++++++++++++++++-------
 hashmap.h                           |  3 +-
 3 files changed, 47 insertions(+), 14 deletions(-)


base-commit: e1cfff676549cdcd702cbac105468723ef2722f4
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-738%2Fdscho%2Fcmake-and-visual-studio-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-738/dscho/cmake-and-visual-studio-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/738

Range-diff vs v1:

  1:  ba314373e9 =  1:  ba314373e9 cmake: ignore files generated by CMake as run in Visual Studio
  2:  05b4b69fee =  2:  05b4b69fee cmake: do find Git for Windows' shell interpreter
  3:  5967822a0c =  3:  5967822a0c cmake: ensure that the `vcpkg` packages are found on Windows
  4:  efc93f1dd9 =  4:  efc93f1dd9 cmake: fall back to using `vcpkg`'s `msgfmt.exe` on Windows
  5:  8b3500a07c =  5:  8b3500a07c cmake: quote the path accurately when editing `test-lib.sh`
  6:  bb8f122cde !  6:  88abbd9a78 cmake (Windows): let the `.dll` files are found when running the tests
     @@ Metadata
      Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
      
       ## Commit message ##
     -    cmake (Windows): let the `.dll` files are found when running the tests
     +    cmake (Windows): let the `.dll` files be found when running the tests
      
          Contrary to Unix-ish platforms, the dependencies' shared libraries are
          not usually found in one central place. In our case, since we use
  7:  dddfa3a9b4 !  7:  26ebeecb14 cmake (Windows): complain when encountering an unknown compiler
     @@ Commit message
          We have some custom handling regarding the link options, which are
          specific to each compiler.
      
     -    Therefore: let's not just continue without setting the link options when
     +    Therefore: let's not just continue without setting the link options if
          configuring for a currently unhandled compiler, but error out.
      
     -    Note: for some reason, the `invalidcontinue.obj` trick seems not to work
     -    in this developer's hands when building Git in Debug mode: the assertion
     -    dialog that is supposed to be suppressed still pops up, complaining
     -    about the `entry` variable being uninitialized when it is used in
     -    `config.c`'s line 1961.
     -
          Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
      
       ## contrib/buildsystems/CMakeLists.txt ##
  8:  3a07bd4916 =  8:  3587ee5e8d cmake (Windows): initialize vcpkg/build dependencies automatically
  9:  f07e421666 !  9:  68a7d984ec cmake (Windows): recommend using Visual Studio's built-in CMake support
     @@ Commit message
          configuration in CMake manually (does not matter whether using the
          command-line or CMake's GUI).
      
     +    While at it, recommend using `contrib/buildsystems/out/` as build
     +    directory also in the part that talks about running CMake manually.
     +
     +    Helped-by: Junio C Hamano <gitster@pobox.com>
          Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
      
       ## contrib/buildsystems/CMakeLists.txt ##
     @@ contrib/buildsystems/CMakeLists.txt
       
      -Instructions to run CMake:
      +Instructions how to use this in Visual Studio:
     -+
     + 
     +-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
      +Open the worktree as a folder. Visual Studio 2019 and later will detect
      +the CMake configuration automatically and set everything up for you,
      +ready to build. You can then run the tests in `t/` via a regular Git Bash.
     -+
     -+Note: Visual Studio also has the option of opening the CMake configuration
     + 
     +-For out of source builds, say build in 'git/git-build/'
     +-	`mkdir git-build;cd git-build; cmake ../contrib/buildsystems/`
     +-This will build the git binaries in git-build directory
     ++Note: Visual Studio also has the option of opening `CMakeLists.txt`
      +directly; Using this option, Visual Studio will not find the source code,
      +though, therefore the `File>Open>Folder...` option is preferred.
      +
      +Instructions to run CMake manually:
     ++
     ++    mkdir -p contrib/buildsystems/out
     ++    cd contrib/buildsystems/out
     ++    cmake ../ -DCMAKE_BUILD_TYPE=Release
     ++
     ++This will build the git binaries in contrib/buildsystems/out
     ++directory (our top-level .gitignore file knows to ignore contents of
     ++this directory).
       
     - cmake `relative-path-to-CMakeLists.txt` -DCMAKE_BUILD_TYPE=Release
     - Eg.
     + Possible build configurations(-DCMAKE_BUILD_TYPE) with corresponding
     + compiler flags
 10:  dc46d39611 <  -:  ---------- hashmap_for_each_entry(): work around MSVC's run-time check failure #3
  -:  ---------- > 10:  152705bbc6 hashmap_for_each_entry(): workaround MSVC's runtime check failure #3

-- 
gitgitgadget

^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v2 01/10] cmake: ignore files generated by CMake as run in Visual Studio
  2020-09-26 21:32 ` [PATCH v2 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
@ 2020-09-26 21:32   ` Johannes Schindelin via GitGitGadget
  2020-09-26 21:32   ` [PATCH v2 02/10] cmake: do find Git for Windows' shell interpreter Johannes Schindelin via GitGitGadget
                     ` (9 subsequent siblings)
  10 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-26 21:32 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

As of recent Visual Studio versions, CMake support is built-in:
https://docs.microsoft.com/en-us/cpp/build/cmake-projects-in-visual-studio?view=vs-2019

All that needs to be done is to open the worktree as a folder, and
Visual Studio will find the `CMakeLists.txt` file and automatically
generate the project files.

Let's ignore the entirety of those generated files.

Helped-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index d0f692a355..6521f3cf22 100644
--- a/.gitignore
+++ b/.gitignore
@@ -241,3 +241,4 @@ Release/
 /git.VC.VC.opendb
 /git.VC.db
 *.dSYM
+/contrib/buildsystems/out
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v2 02/10] cmake: do find Git for Windows' shell interpreter
  2020-09-26 21:32 ` [PATCH v2 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
  2020-09-26 21:32   ` [PATCH v2 01/10] cmake: ignore files generated by CMake as run in " Johannes Schindelin via GitGitGadget
@ 2020-09-26 21:32   ` Johannes Schindelin via GitGitGadget
  2020-09-28 11:17     ` Øystein Walle
  2020-09-26 21:32   ` [PATCH v2 03/10] cmake: ensure that the `vcpkg` packages are found on Windows Johannes Schindelin via GitGitGadget
                     ` (8 subsequent siblings)
  10 siblings, 1 reply; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-26 21:32 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

By default, Git for Windows does not install its `sh.exe` into the
`PATH`. However, our current `CMakeLists.txt` expects to find a shell
interpreter in the `PATH`.

So let's fall back to looking in the default location where Git for
Windows _does_ install a relatively convenient `sh.exe`:
`C:\Program Files\Git\bin\sh.exe`

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index 5007f173f1..d14fa4f3dc 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -43,8 +43,11 @@ set(CMAKE_SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/../..)
 
 find_program(SH_EXE sh)
 if(NOT SH_EXE)
-	message(FATAL_ERROR "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/")
+	set(SH_EXE "C:/Program Files/Git/bin/sh.exe")
+	if(NOT EXISTS ${SH_EXE})
+		message(FATAL_ERROR "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/")
+	endif()
 endif()
 
 #Create GIT-VERSION-FILE using GIT-VERSION-GEN
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v2 03/10] cmake: ensure that the `vcpkg` packages are found on Windows
  2020-09-26 21:32 ` [PATCH v2 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
  2020-09-26 21:32   ` [PATCH v2 01/10] cmake: ignore files generated by CMake as run in " Johannes Schindelin via GitGitGadget
  2020-09-26 21:32   ` [PATCH v2 02/10] cmake: do find Git for Windows' shell interpreter Johannes Schindelin via GitGitGadget
@ 2020-09-26 21:32   ` Johannes Schindelin via GitGitGadget
  2020-09-26 21:32   ` [PATCH v2 04/10] cmake: fall back to using `vcpkg`'s `msgfmt.exe` " Johannes Schindelin via GitGitGadget
                     ` (7 subsequent siblings)
  10 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-26 21:32 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

On Windows, we use the `vcpkg` project to manage the dependencies, via
`compat/vcbuild/`. Let's make sure that these dependencies are found by
default.

This is needed because we are about to recommend loading the Git
worktree as a folder into Visual Studio, relying on the automatic CMake
support (which would make it relatively cumbersome to adjust the search
path used by CMake manually).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index d14fa4f3dc..16014ac4f7 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -40,6 +40,13 @@ cmake_minimum_required(VERSION 3.14)
 
 #set the source directory to root of git
 set(CMAKE_SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/../..)
+if(WIN32)
+	set(VCPKG_DIR "${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg")
+	list(APPEND CMAKE_PREFIX_PATH "${VCPKG_DIR}/installed/x64-windows")
+
+	# In the vcpkg edition, we need this to be able to link to libcurl
+	set(CURL_NO_CURL_CMAKE ON)
+endif()
 
 find_program(SH_EXE sh)
 if(NOT SH_EXE)
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v2 04/10] cmake: fall back to using `vcpkg`'s `msgfmt.exe` on Windows
  2020-09-26 21:32 ` [PATCH v2 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                     ` (2 preceding siblings ...)
  2020-09-26 21:32   ` [PATCH v2 03/10] cmake: ensure that the `vcpkg` packages are found on Windows Johannes Schindelin via GitGitGadget
@ 2020-09-26 21:32   ` Johannes Schindelin via GitGitGadget
  2020-09-26 21:32   ` [PATCH v2 05/10] cmake: quote the path accurately when editing `test-lib.sh` Johannes Schindelin via GitGitGadget
                     ` (6 subsequent siblings)
  10 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-26 21:32 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

We are already relying on `vcpkg` to manage our dependencies, including
`libiconv`. Let's also use the `msgfmt.exe` from there.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index 16014ac4f7..acb197fba5 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -155,7 +155,11 @@ endif()
 
 find_program(MSGFMT_EXE msgfmt)
 if(NOT MSGFMT_EXE)
-	message(WARNING "Text Translations won't be build")
+	set(MSGFMT_EXE ${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg/downloads/tools/msys2/msys64/usr/bin/msgfmt.exe)
+	if(NOT EXISTS ${MSGFMT_EXE})
+		message(WARNING "Text Translations won't be build")
+		unset(MSGFMT_EXE)
+	endif()
 endif()
 
 #Force all visual studio outputs to CMAKE_BINARY_DIR
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v2 05/10] cmake: quote the path accurately when editing `test-lib.sh`
  2020-09-26 21:32 ` [PATCH v2 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                     ` (3 preceding siblings ...)
  2020-09-26 21:32   ` [PATCH v2 04/10] cmake: fall back to using `vcpkg`'s `msgfmt.exe` " Johannes Schindelin via GitGitGadget
@ 2020-09-26 21:32   ` Johannes Schindelin via GitGitGadget
  2020-09-26 21:32   ` [PATCH v2 06/10] cmake (Windows): let the `.dll` files be found when running the tests Johannes Schindelin via GitGitGadget
                     ` (5 subsequent siblings)
  10 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-26 21:32 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

By default, the build directory will be called something like
`contrib/buildsystems/out/build/x64-Debug (default)` (note the space and
the parentheses). We need to make sure that such a path is quoted
properly when editing the assignment of the `GIT_BUILD_DIR` variable.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index acb197fba5..e66ae137c2 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -952,7 +952,7 @@ if(NOT ${CMAKE_BINARY_DIR}/CMakeCache.txt STREQUAL ${CACHE_PATH})
 	file(WRITE ${CMAKE_BINARY_DIR}/CTestCustom.cmake
 		"file(STRINGS ${CMAKE_SOURCE_DIR}/t/test-lib.sh GIT_BUILD_DIR_REPL REGEX \"GIT_BUILD_DIR=(.*)\")\n"
 		"file(STRINGS ${CMAKE_SOURCE_DIR}/t/test-lib.sh content NEWLINE_CONSUME)\n"
-		"string(REPLACE \"\${GIT_BUILD_DIR_REPL}\" \"GIT_BUILD_DIR=\\\"$TEST_DIRECTORY\\\"/../${BUILD_DIR_RELATIVE}\" content \"\${content}\")\n"
+		"string(REPLACE \"\${GIT_BUILD_DIR_REPL}\" \"GIT_BUILD_DIR=\\\"$TEST_DIRECTORY/../${BUILD_DIR_RELATIVE}\\\"\" content \"\${content}\")\n"
 		"file(WRITE ${CMAKE_SOURCE_DIR}/t/test-lib.sh \${content})")
 	#misc copies
 	file(COPY ${CMAKE_SOURCE_DIR}/t/chainlint.sed DESTINATION ${CMAKE_BINARY_DIR}/t/)
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v2 06/10] cmake (Windows): let the `.dll` files be found when running the tests
  2020-09-26 21:32 ` [PATCH v2 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                     ` (4 preceding siblings ...)
  2020-09-26 21:32   ` [PATCH v2 05/10] cmake: quote the path accurately when editing `test-lib.sh` Johannes Schindelin via GitGitGadget
@ 2020-09-26 21:32   ` Johannes Schindelin via GitGitGadget
  2020-09-26 21:32   ` [PATCH v2 07/10] cmake (Windows): complain when encountering an unknown compiler Johannes Schindelin via GitGitGadget
                     ` (4 subsequent siblings)
  10 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-26 21:32 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Contrary to Unix-ish platforms, the dependencies' shared libraries are
not usually found in one central place. In our case, since we use
`vcpkg`, they are to be found inside the `compat/vcbuild/vcpkg/` tree.

Let's make sure that they are in the search path when running the tests.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index e66ae137c2..5a4e0ccb01 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -942,6 +942,9 @@ file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "X='${EXE_EXTENSION}'\n")
 file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "NO_GETTEXT='${NO_GETTEXT}'\n")
 file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "RUNTIME_PREFIX='${RUNTIME_PREFIX}'\n")
 file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "NO_PYTHON='${NO_PYTHON}'\n")
+if(WIN32)
+	file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "PATH=\"$PATH:$TEST_DIRECTORY/../compat/vcbuild/vcpkg/installed/x64-windows/bin\"\n")
+endif()
 
 #Make the tests work when building out of the source tree
 get_filename_component(CACHE_PATH ${CMAKE_CURRENT_LIST_DIR}/../../CMakeCache.txt ABSOLUTE)
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v2 07/10] cmake (Windows): complain when encountering an unknown compiler
  2020-09-26 21:32 ` [PATCH v2 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                     ` (5 preceding siblings ...)
  2020-09-26 21:32   ` [PATCH v2 06/10] cmake (Windows): let the `.dll` files be found when running the tests Johannes Schindelin via GitGitGadget
@ 2020-09-26 21:32   ` Johannes Schindelin via GitGitGadget
  2020-09-26 21:32   ` [PATCH v2 08/10] cmake (Windows): initialize vcpkg/build dependencies automatically Johannes Schindelin via GitGitGadget
                     ` (3 subsequent siblings)
  10 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-26 21:32 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

We have some custom handling regarding the link options, which are
specific to each compiler.

Therefore: let's not just continue without setting the link options if
configuring for a currently unhandled compiler, but error out.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index 5a4e0ccb01..d21849b730 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -620,6 +620,8 @@ if(WIN32)
 		target_link_options(common-main PUBLIC -municode -Wl,-nxcompat -Wl,-dynamicbase -Wl,-entry:wmainCRTStartup -Wl,invalidcontinue.obj)
 	elseif(CMAKE_C_COMPILER_ID STREQUAL "MSVC")
 		target_link_options(common-main PUBLIC /IGNORE:4217 /IGNORE:4049 /NOLOGO /ENTRY:wmainCRTStartup /SUBSYSTEM:CONSOLE invalidcontinue.obj)
+	else()
+		message(FATAL_ERROR "Unhandled compiler: ${CMAKE_C_COMPILER_ID}")
 	endif()
 elseif(UNIX)
 	target_link_libraries(common-main pthread rt)
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v2 08/10] cmake (Windows): initialize vcpkg/build dependencies automatically
  2020-09-26 21:32 ` [PATCH v2 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                     ` (6 preceding siblings ...)
  2020-09-26 21:32   ` [PATCH v2 07/10] cmake (Windows): complain when encountering an unknown compiler Johannes Schindelin via GitGitGadget
@ 2020-09-26 21:32   ` Johannes Schindelin via GitGitGadget
  2020-09-26 21:32   ` [PATCH v2 09/10] cmake (Windows): recommend using Visual Studio's built-in CMake support Johannes Schindelin via GitGitGadget
                     ` (2 subsequent siblings)
  10 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-26 21:32 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The idea of having CMake support in Git's source tree is to enable
contributors on Windows to start contributing with little effort. To
that end, we just added some sensible defaults that will let users open
the worktree in Visual Studio and start building.

This expects the dependencies (such as zlib) to be available already,
though. If they are not available, we expect the user to run
`compat/vcbuild/vcpkg_install.bat`.

Rather than requiring this step to be manual, detect the situation and
run it as part of the CMake configuration step.

This concludes our journey to make it as effortless as possible to start
developing Git in Visual Studio: all the developer needs to do is to
clone Git's repository, open the worktree via `File>Open>Folder...` and
wait for CMake to finish configuring.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index d21849b730..1eaeb8b8e0 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -42,6 +42,10 @@ cmake_minimum_required(VERSION 3.14)
 set(CMAKE_SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/../..)
 if(WIN32)
 	set(VCPKG_DIR "${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg")
+	if(NOT EXISTS ${VCPKG_DIR})
+		message("Initializinge vcpkg and building the Git's dependencies (this will take a while...)")
+		execute_process(COMMAND ${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg_install.bat)
+	endif()
 	list(APPEND CMAKE_PREFIX_PATH "${VCPKG_DIR}/installed/x64-windows")
 
 	# In the vcpkg edition, we need this to be able to link to libcurl
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v2 09/10] cmake (Windows): recommend using Visual Studio's built-in CMake support
  2020-09-26 21:32 ` [PATCH v2 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                     ` (7 preceding siblings ...)
  2020-09-26 21:32   ` [PATCH v2 08/10] cmake (Windows): initialize vcpkg/build dependencies automatically Johannes Schindelin via GitGitGadget
@ 2020-09-26 21:32   ` Johannes Schindelin via GitGitGadget
  2020-09-26 21:32   ` [PATCH v2 10/10] hashmap_for_each_entry(): workaround MSVC's runtime check failure #3 Junio C Hamano via GitGitGadget
  2020-09-28 21:09   ` [PATCH v3 00/11] CMake and Visual Studio Johannes Schindelin via GitGitGadget
  10 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-26 21:32 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

It is a lot more convenient to use than having to specify the
configuration in CMake manually (does not matter whether using the
command-line or CMake's GUI).

While at it, recommend using `contrib/buildsystems/out/` as build
directory also in the part that talks about running CMake manually.

Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 26 +++++++++++++++++---------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index 1eaeb8b8e0..de92e4fe2d 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -4,17 +4,25 @@
 
 #[[
 
-Instructions to run CMake:
+Instructions how to use this in Visual Studio:
 
-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
+Open the worktree as a folder. Visual Studio 2019 and later will detect
+the CMake configuration automatically and set everything up for you,
+ready to build. You can then run the tests in `t/` via a regular Git Bash.
 
-For out of source builds, say build in 'git/git-build/'
-	`mkdir git-build;cd git-build; cmake ../contrib/buildsystems/`
-This will build the git binaries in git-build directory
+Note: Visual Studio also has the option of opening `CMakeLists.txt`
+directly; Using this option, Visual Studio will not find the source code,
+though, therefore the `File>Open>Folder...` option is preferred.
+
+Instructions to run CMake manually:
+
+    mkdir -p contrib/buildsystems/out
+    cd contrib/buildsystems/out
+    cmake ../ -DCMAKE_BUILD_TYPE=Release
+
+This will build the git binaries in contrib/buildsystems/out
+directory (our top-level .gitignore file knows to ignore contents of
+this directory).
 
 Possible build configurations(-DCMAKE_BUILD_TYPE) with corresponding
 compiler flags
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v2 10/10] hashmap_for_each_entry(): workaround MSVC's runtime check failure #3
  2020-09-26 21:32 ` [PATCH v2 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                     ` (8 preceding siblings ...)
  2020-09-26 21:32   ` [PATCH v2 09/10] cmake (Windows): recommend using Visual Studio's built-in CMake support Johannes Schindelin via GitGitGadget
@ 2020-09-26 21:32   ` Junio C Hamano via GitGitGadget
  2020-09-28 21:09   ` [PATCH v3 00/11] CMake and Visual Studio Johannes Schindelin via GitGitGadget
  10 siblings, 0 replies; 70+ messages in thread
From: Junio C Hamano via GitGitGadget @ 2020-09-26 21:32 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Johannes Schindelin, Junio C Hamano

From: Junio C Hamano <gitster@pobox.com>

The OFFSETOF_VAR(var, member) macro is implemented in terms of
offsetof(typeof(*var), member) with compilers that know typeof(),
but its fallback implemenation compares &(var->member) and (var) and
count the distance in bytes, i.e.

    ((uintptr_t)&(var)->member - (uintptr_t)(var))

MSVC's runtime check, when fed an uninitialized 'var', flags this as
a use of an uninitialized variable (and that is legit---uninitialized
contents of 'var' is subtracted) in a debug build.

After auditing all 6 uses of OFFSETOF_VAR(), 1 of them does feed a
potentially uninitialized 'var' to the macro in the beginning of the
for() loop:

    #define hashmap_for_each_entry(map, iter, var, member) \
            for (var = hashmap_iter_first_entry_offset(map, iter, \
                                                    OFFSETOF_VAR(var, member)); \
                    var; \
                    var = hashmap_iter_next_entry_offset(iter, \
                                                    OFFSETOF_VAR(var, member)))

We can work around this by making sure that var has _some_ value
when OFFSETOF_VAR() is called.  Strictly speaking, it invites
undefined behaviour to use NULL here if we end up with pointer
comparison, but MSVC runtime seems to be happy with it, and most
other systems have typeof() and don't even need pointer comparison
fallback code.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 hashmap.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hashmap.h b/hashmap.h
index ef220de4c6..b011b394fe 100644
--- a/hashmap.h
+++ b/hashmap.h
@@ -449,7 +449,8 @@ static inline struct hashmap_entry *hashmap_iter_first(struct hashmap *map,
  * containing a @member which is a "struct hashmap_entry"
  */
 #define hashmap_for_each_entry(map, iter, var, member) \
-	for (var = hashmap_iter_first_entry_offset(map, iter, \
+	for (var = NULL, /* for systems without typeof */ \
+	     var = hashmap_iter_first_entry_offset(map, iter, \
 						OFFSETOF_VAR(var, member)); \
 		var; \
 		var = hashmap_iter_next_entry_offset(iter, \
-- 
gitgitgadget

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [PATCH 02/10] cmake: do find Git for Windows' shell interpreter
  2020-09-26 20:32     ` Johannes Schindelin
@ 2020-09-27  2:25       ` Đoàn Trần Công Danh
  2020-09-28 13:56         ` Johannes Schindelin
  0 siblings, 1 reply; 70+ messages in thread
From: Đoàn Trần Công Danh @ 2020-09-27  2:25 UTC (permalink / raw)
  To: Johannes Schindelin
  Cc: Sibi Siddharthan, Johannes Schindelin via GitGitGadget, git,
	SZEDER Gábor

On 2020-09-26 22:32:25+0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Since the Git-for-windows installer does append
> > 'your_installation_directory'/Git/bin to the PATH variable, it should
> > be fine.
> 
> No, it does not. Quite purposefully so.
> 
> The `/bin/` directory is kind of a hack to reinstate _some_ level of
> support for use cases that relied on Git for Windows v1.x installing its
> binaries into that directory (v2.x distributes them between `/usr/bin/`
> and `/mingw64/bin/`).
> 
> What _does_ get appended, at least by default, is the `/cmd/` directory
> (which does _not_ contain `sh.exe`).
> 
> Now, there _is_ an option in the Git for Windows installer to append all
> of its Unix tools to the `PATH`, but it is highly discouraged to do so.

I agree with this decision.

> 
> > I personally don't install my dev tools(except Visual Studio) to
> > Program Files(because of the _space_), it messes up the Makefiles.
> 
> Sure, and that's your prerogative. There's unfortunately no good way to
> support your use case.
> 
> Luckily, the vast majority of Git for Windows' users do not change the
> default location, and this patch is for them. (And "them" in this case
> includes me, personally ;-))

This doesn't fit into my view of Git for Windows' users
For some users that have the Administrator right, it's the default
location if they grant the Administrator right for the installer.

For those poor souls that works for enterprise companies, and thoses
that not feel comfortable give Administrator right to _another_
installer, the installer will install into (hopeful, I type it right):

	%USERPROFILE%/AppData/Local/Programs/Git

I think it's better to offer SH_EXE as an OPTION, let user specify it
as will. And we'll search in PATH if it's not specified, fallback to
2 default value if not found.

-- 
Danh

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [PATCH v2 02/10] cmake: do find Git for Windows' shell interpreter
  2020-09-26 21:32   ` [PATCH v2 02/10] cmake: do find Git for Windows' shell interpreter Johannes Schindelin via GitGitGadget
@ 2020-09-28 11:17     ` Øystein Walle
  2020-09-28 19:39       ` Johannes Schindelin
  0 siblings, 1 reply; 70+ messages in thread
From: Øystein Walle @ 2020-09-28 11:17 UTC (permalink / raw)
  To: gitgitgadget
  Cc: Johannes.Schindelin, congdanhqx, git, sibisiddharthan.github,
	sunshine, szeder.dev

>  find_program(SH_EXE sh)
>  if(NOT SH_EXE)
> -	message(FATAL_ERROR "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/")
> +	set(SH_EXE "C:/Program Files/Git/bin/sh.exe")
> +	if(NOT EXISTS ${SH_EXE})
> +		message(FATAL_ERROR "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/")
> +	endif()
>  endif()

You can write the find_program() command more succinctly as:

	find_program(SH_EXE sh PATHS "C:/Program Files/Git/bin")

PATHS is is a list of extra directories to search, which are usually hard-coded
guesses[1]. This way we avoid an extra check and indentation level.

I found my Visual Studio installation already contains a sh.exe.  I think it
ships with VS by default; I can't even find a way to remove it. It's located
at:

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\Git\usr\bin\sh.exe

When I started writing this up I figured that could serve as an additional
fallback. However, if I use that shell I have to add (...)/usr/bin to PATH as
the various scripts need expr and sed among other things. I get the same result
if I search "C:/Program Files/Git/usr/bin", but there is no equivalent
(...)/bin in the Git included with VS for some reason.

For the curious I have attached the patch that ended up working, but I doubt
it's worth including (except the simplified if(NOT...) logic).

Øsse.

[1]: https://cmake.org/cmake/help/latest/command/find_program.html

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index 5007f173f1..baa46e4e97 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -41,10 +41,17 @@ cmake_minimum_required(VERSION 3.14)
 #set the source directory to root of git
 set(CMAKE_SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/../..)
 
-find_program(SH_EXE sh)
+find_program(SH_EXE sh
+    PATHS  "C:/Program Files/Git/bin"
+           "$ENV{VSINSTALLDIR}/Common7/IDE/CommonExtensions/Microsoft/TeamFoundation/Team Explorer/Git/usr/bin"
+ )
 if(NOT SH_EXE)
 	message(FATAL_ERROR "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/")
+else()
+    # Make sure various utilities are available in PATH
+    get_filename_component(dir "${SH_EXE}" DIRECTORY)
+    set(ENV{PATH} "$ENV{PATH};${dir}")
 endif()
 
 #Create GIT-VERSION-FILE using GIT-VERSION-GEN


^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [PATCH 02/10] cmake: do find Git for Windows' shell interpreter
  2020-09-27  2:25       ` Đoàn Trần Công Danh
@ 2020-09-28 13:56         ` Johannes Schindelin
  2020-09-29 14:04           ` Đoàn Trần Công Danh
  0 siblings, 1 reply; 70+ messages in thread
From: Johannes Schindelin @ 2020-09-28 13:56 UTC (permalink / raw)
  To: Đoàn Trần Công Danh
  Cc: Sibi Siddharthan, Johannes Schindelin via GitGitGadget, git,
	SZEDER Gábor

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

Hi Danh,

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

> On 2020-09-26 22:32:25+0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > > I personally don't install my dev tools(except Visual Studio) to
> > > Program Files(because of the _space_), it messes up the Makefiles.
> >
> > Sure, and that's your prerogative. There's unfortunately no good way to
> > support your use case.
> >
> > Luckily, the vast majority of Git for Windows' users do not change the
> > default location, and this patch is for them. (And "them" in this case
> > includes me, personally ;-))
>
> This doesn't fit into my view of Git for Windows' users
> For some users that have the Administrator right, it's the default
> location if they grant the Administrator right for the installer.
>
> For those poor souls that works for enterprise companies, and thoses
> that not feel comfortable give Administrator right to _another_
> installer, the installer will install into (hopeful, I type it right):
>
> 	%USERPROFILE%/AppData/Local/Programs/Git

Those poor souls that work for enterprise companies often have Git for
Windows installed by default. And of course, that default would be in
`C:\Program Files\Git`.

> I think it's better to offer SH_EXE as an OPTION, let user specify it
> as will. And we'll search in PATH if it's not specified, fallback to
> 2 default value if not found.

That's exactly as it is right now. You can specify `SH_EXE` (but only if
running CMake manually, not via Visual Studio). If you don't, it searches
`PATH`, and with my patch it then falls back to trying to find `sh.exe` in
Git for Windows' default location.

So I think we're in agreement here?

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [PATCH v2 02/10] cmake: do find Git for Windows' shell interpreter
  2020-09-28 11:17     ` Øystein Walle
@ 2020-09-28 19:39       ` Johannes Schindelin
  0 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin @ 2020-09-28 19:39 UTC (permalink / raw)
  To: Øystein Walle
  Cc: gitgitgadget, congdanhqx, git, sibisiddharthan.github, sunshine,
	szeder.dev

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

Hi Øystein,

On Mon, 28 Sep 2020, Øystein Walle wrote:

> >  find_program(SH_EXE sh)
> >  if(NOT SH_EXE)
> > -	message(FATAL_ERROR "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/")
> > +	set(SH_EXE "C:/Program Files/Git/bin/sh.exe")
> > +	if(NOT EXISTS ${SH_EXE})
> > +		message(FATAL_ERROR "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/")
> > +	endif()
> >  endif()
>
> You can write the find_program() command more succinctly as:
>
> 	find_program(SH_EXE sh PATHS "C:/Program Files/Git/bin")
>
> PATHS is is a list of extra directories to search, which are usually hard-coded
> guesses[1]. This way we avoid an extra check and indentation level.

Thank you, I was not aware of this neat feature.

> I found my Visual Studio installation already contains a sh.exe.  I think it
> ships with VS by default; I can't even find a way to remove it. It's located
> at:
>
> C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\Git\usr\bin\sh.exe
>
> When I started writing this up I figured that could serve as an additional
> fallback. However, if I use that shell I have to add (...)/usr/bin to PATH as
> the various scripts need expr and sed among other things. I get the same result
> if I search "C:/Program Files/Git/usr/bin", but there is no equivalent
> (...)/bin in the Git included with VS for some reason.

Indeed. This is what I get in that case:

-- snip --
1> [CMake] Generating  GIT-VERSION-FILE
1> [CMake] C:/git-sdk-64/usr/src/vs2017-test/contrib/buildsystems/../../GIT-VERSION-GEN: line 24: sed: command not found
1> [CMake] C:/git-sdk-64/usr/src/vs2017-test/contrib/buildsystems/../../GIT-VERSION-GEN: line 29: expr: command not found
1> [CMake] GIT_VERSION =
1> [CMake] CMake Error at C:\git-sdk-64\usr\src\vs2017-test\contrib\buildsystems\CMakeLists.txt:79 (string):
1> [CMake]   string sub-command FIND requires 3 or 4 parameters.
1> [CMake]
1> [CMake]
1> [CMake] CMake Error at C:\git-sdk-64\usr\src\vs2017-test\contrib\buildsystems\CMakeLists.txt:83 (string):
1> [CMake]   string sub-command REGEX, mode MATCH needs at least 5 arguments total to
1> [CMake]   command.
1> [CMake]
1> [CMake]
1> [CMake] CMake Error at C:\git-sdk-64\usr\src\vs2017-test\contrib\buildsystems\CMakeLists.txt:87 (project):
1> [CMake]   VERSION ".0" format invalid.
-- snap --

The explanation is pretty simple: you cannot just call into `sh.exe` via
an absolute path and expect it to add its containing directory to the
`PATH`. It does not, and the symptom is that neither `sed` nor `expr` are
found.

One solution is to add it to the `PATH` manually, which is the original
expectation in our `CMakeLists.txt` version.

Another solution is to point it to `C:\Program Files\Git\bin\sh.exe` which
is not, in fact, a shell, but a small wrapper executable whose job it is
to set up a couple environment variables (`PATH` being one of them) and
then spawning the _actual_ `sh.exe`. The source code for that wrapper:
https://github.com/git-for-windows/MINGW-packages/blob/main/mingw-w64-git/git-wrapper.c

As you figured out, it is _not_ enough to use `...\usr\bin\sh.exe`
directly without adjusting the `PATH`.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v3 00/11] CMake and Visual Studio
  2020-09-26 21:32 ` [PATCH v2 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                     ` (9 preceding siblings ...)
  2020-09-26 21:32   ` [PATCH v2 10/10] hashmap_for_each_entry(): workaround MSVC's runtime check failure #3 Junio C Hamano via GitGitGadget
@ 2020-09-28 21:09   ` Johannes Schindelin via GitGitGadget
  2020-09-28 21:09     ` [PATCH v3 01/11] cmake: ignore files generated by CMake as run in " Johannes Schindelin via GitGitGadget
                       ` (11 more replies)
  10 siblings, 12 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-28 21:09 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Øystein Walle, Johannes Schindelin

The intention of this patch series is to make it as easy as possible for a
Visual Studio user to start building Git from scratch. The idea is to

 * clone Git's source code,
 * open it in Visual Studio via File>Open>Folder...
 * let CMake configure things (and vcpkg build the dependencies, which will
   take a while), and
 * start the build.

It does require a Git for Windows to be installed so that the source can be
cloned, but also to run the shell script parts of the CMake configuration,
and also to run the tests.

This patch series replaces the patch "Ignore files generated by CMake" I
sent via https://github.com/gitgitgadget/git/pull/735.

Changes since v2:

 * Fixed a typo in the message when msgfmt.exe is not found.
 * Simplified the logic to find sh.exe (thanks Øystein).

Changes since v1:

 * Touched up a couple commit messages in response to reviewer comments
 * Adjusted the instructions at the top of CMakeLists.txt so that the part
   talking about running CMake manually also talks about using 
   contrib/buildsystems/out/ as build directory (in line with the part
   talking about Visual Studio's out-of-the-box experience)
 * Replaced patch 10/10 with Junio's much more elegant solution of editing
   the hashmap_for_each_entry() macro instead of all of its callers.

Johannes Schindelin (10):
  cmake: ignore files generated by CMake as run in Visual Studio
  cmake: do find Git for Windows' shell interpreter
  cmake: ensure that the `vcpkg` packages are found on Windows
  cmake: fall back to using `vcpkg`'s `msgfmt.exe` on Windows
  cmake: quote the path accurately when editing `test-lib.sh`
  cmake (Windows): let the `.dll` files be found when running the tests
  cmake (Windows): complain when encountering an unknown compiler
  cmake (Windows): initialize vcpkg/build dependencies automatically
  cmake (Windows): recommend using Visual Studio's built-in CMake
    support
  cmake: fix typo in message when `msgfmt` was not found

Junio C Hamano (1):
  hashmap_for_each_entry(): workaround MSVC's runtime check failure #3

 .gitignore                          |  1 +
 contrib/buildsystems/CMakeLists.txt | 52 ++++++++++++++++++++++-------
 hashmap.h                           |  3 +-
 3 files changed, 43 insertions(+), 13 deletions(-)


base-commit: 9bc233ae1cf19a49e51842c7959d80a675dbd1c0
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-738%2Fdscho%2Fcmake-and-visual-studio-v3
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-738/dscho/cmake-and-visual-studio-v3
Pull-Request: https://github.com/gitgitgadget/git/pull/738

Range-diff vs v2:

  1:  ba314373e9 =  1:  9c7a964519 cmake: ignore files generated by CMake as run in Visual Studio
  2:  05b4b69fee <  -:  ---------- cmake: do find Git for Windows' shell interpreter
  -:  ---------- >  2:  3b467360bb cmake: do find Git for Windows' shell interpreter
  3:  5967822a0c !  3:  a49b28e001 cmake: ensure that the `vcpkg` packages are found on Windows
     @@ contrib/buildsystems/CMakeLists.txt: cmake_minimum_required(VERSION 3.14)
      +	set(CURL_NO_CURL_CMAKE ON)
      +endif()
       
     - find_program(SH_EXE sh)
     + find_program(SH_EXE sh PATHS "C:/Program Files/Git/bin")
       if(NOT SH_EXE)
  4:  efc93f1dd9 =  4:  f1baf0f974 cmake: fall back to using `vcpkg`'s `msgfmt.exe` on Windows
  5:  8b3500a07c =  5:  8380aa55ab cmake: quote the path accurately when editing `test-lib.sh`
  6:  88abbd9a78 =  6:  f61c3ef442 cmake (Windows): let the `.dll` files be found when running the tests
  7:  26ebeecb14 =  7:  7a4346a437 cmake (Windows): complain when encountering an unknown compiler
  8:  3587ee5e8d =  8:  7c1601c7e3 cmake (Windows): initialize vcpkg/build dependencies automatically
  9:  68a7d984ec =  9:  ec182738f0 cmake (Windows): recommend using Visual Studio's built-in CMake support
 10:  152705bbc6 = 10:  38cef4deb5 hashmap_for_each_entry(): workaround MSVC's runtime check failure #3
  -:  ---------- > 11:  c3e235fe39 cmake: fix typo in message when `msgfmt` was not found

-- 
gitgitgadget

^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v3 01/11] cmake: ignore files generated by CMake as run in Visual Studio
  2020-09-28 21:09   ` [PATCH v3 00/11] CMake and Visual Studio Johannes Schindelin via GitGitGadget
@ 2020-09-28 21:09     ` Johannes Schindelin via GitGitGadget
  2020-09-28 21:09     ` [PATCH v3 02/11] cmake: do find Git for Windows' shell interpreter Johannes Schindelin via GitGitGadget
                       ` (10 subsequent siblings)
  11 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-28 21:09 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Øystein Walle, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

As of recent Visual Studio versions, CMake support is built-in:
https://docs.microsoft.com/en-us/cpp/build/cmake-projects-in-visual-studio?view=vs-2019

All that needs to be done is to open the worktree as a folder, and
Visual Studio will find the `CMakeLists.txt` file and automatically
generate the project files.

Let's ignore the entirety of those generated files.

Helped-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index 800b812c6a..6232d33924 100644
--- a/.gitignore
+++ b/.gitignore
@@ -242,3 +242,4 @@ Release/
 /git.VC.VC.opendb
 /git.VC.db
 *.dSYM
+/contrib/buildsystems/out
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v3 02/11] cmake: do find Git for Windows' shell interpreter
  2020-09-28 21:09   ` [PATCH v3 00/11] CMake and Visual Studio Johannes Schindelin via GitGitGadget
  2020-09-28 21:09     ` [PATCH v3 01/11] cmake: ignore files generated by CMake as run in " Johannes Schindelin via GitGitGadget
@ 2020-09-28 21:09     ` Johannes Schindelin via GitGitGadget
  2020-09-28 21:09     ` [PATCH v3 03/11] cmake: ensure that the `vcpkg` packages are found on Windows Johannes Schindelin via GitGitGadget
                       ` (9 subsequent siblings)
  11 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-28 21:09 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Øystein Walle, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

By default, Git for Windows does not install its `sh.exe` into the
`PATH`. However, our current `CMakeLists.txt` expects to find a shell
interpreter in the `PATH`.

So let's fall back to looking in the default location where Git for
Windows _does_ install a relatively convenient `sh.exe`:
`C:\Program Files\Git\bin\sh.exe`

Helped-by: Øystein Walle <oystwa@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index 5007f173f1..1847a6fd58 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -41,7 +41,7 @@ cmake_minimum_required(VERSION 3.14)
 #set the source directory to root of git
 set(CMAKE_SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/../..)
 
-find_program(SH_EXE sh)
+find_program(SH_EXE sh PATHS "C:/Program Files/Git/bin")
 if(NOT SH_EXE)
 	message(FATAL_ERROR "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/")
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v3 03/11] cmake: ensure that the `vcpkg` packages are found on Windows
  2020-09-28 21:09   ` [PATCH v3 00/11] CMake and Visual Studio Johannes Schindelin via GitGitGadget
  2020-09-28 21:09     ` [PATCH v3 01/11] cmake: ignore files generated by CMake as run in " Johannes Schindelin via GitGitGadget
  2020-09-28 21:09     ` [PATCH v3 02/11] cmake: do find Git for Windows' shell interpreter Johannes Schindelin via GitGitGadget
@ 2020-09-28 21:09     ` Johannes Schindelin via GitGitGadget
  2020-09-28 21:09     ` [PATCH v3 04/11] cmake: fall back to using `vcpkg`'s `msgfmt.exe` " Johannes Schindelin via GitGitGadget
                       ` (8 subsequent siblings)
  11 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-28 21:09 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Øystein Walle, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

On Windows, we use the `vcpkg` project to manage the dependencies, via
`compat/vcbuild/`. Let's make sure that these dependencies are found by
default.

This is needed because we are about to recommend loading the Git
worktree as a folder into Visual Studio, relying on the automatic CMake
support (which would make it relatively cumbersome to adjust the search
path used by CMake manually).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index 1847a6fd58..12268f61ba 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -40,6 +40,13 @@ cmake_minimum_required(VERSION 3.14)
 
 #set the source directory to root of git
 set(CMAKE_SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/../..)
+if(WIN32)
+	set(VCPKG_DIR "${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg")
+	list(APPEND CMAKE_PREFIX_PATH "${VCPKG_DIR}/installed/x64-windows")
+
+	# In the vcpkg edition, we need this to be able to link to libcurl
+	set(CURL_NO_CURL_CMAKE ON)
+endif()
 
 find_program(SH_EXE sh PATHS "C:/Program Files/Git/bin")
 if(NOT SH_EXE)
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v3 04/11] cmake: fall back to using `vcpkg`'s `msgfmt.exe` on Windows
  2020-09-28 21:09   ` [PATCH v3 00/11] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                       ` (2 preceding siblings ...)
  2020-09-28 21:09     ` [PATCH v3 03/11] cmake: ensure that the `vcpkg` packages are found on Windows Johannes Schindelin via GitGitGadget
@ 2020-09-28 21:09     ` Johannes Schindelin via GitGitGadget
  2020-09-28 21:09     ` [PATCH v3 05/11] cmake: quote the path accurately when editing `test-lib.sh` Johannes Schindelin via GitGitGadget
                       ` (7 subsequent siblings)
  11 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-28 21:09 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Øystein Walle, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

We are already relying on `vcpkg` to manage our dependencies, including
`libiconv`. Let's also use the `msgfmt.exe` from there.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index 12268f61ba..683cf38263 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -152,7 +152,11 @@ endif()
 
 find_program(MSGFMT_EXE msgfmt)
 if(NOT MSGFMT_EXE)
-	message(WARNING "Text Translations won't be build")
+	set(MSGFMT_EXE ${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg/downloads/tools/msys2/msys64/usr/bin/msgfmt.exe)
+	if(NOT EXISTS ${MSGFMT_EXE})
+		message(WARNING "Text Translations won't be build")
+		unset(MSGFMT_EXE)
+	endif()
 endif()
 
 #Force all visual studio outputs to CMAKE_BINARY_DIR
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v3 05/11] cmake: quote the path accurately when editing `test-lib.sh`
  2020-09-28 21:09   ` [PATCH v3 00/11] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                       ` (3 preceding siblings ...)
  2020-09-28 21:09     ` [PATCH v3 04/11] cmake: fall back to using `vcpkg`'s `msgfmt.exe` " Johannes Schindelin via GitGitGadget
@ 2020-09-28 21:09     ` Johannes Schindelin via GitGitGadget
  2020-09-28 21:09     ` [PATCH v3 06/11] cmake (Windows): let the `.dll` files be found when running the tests Johannes Schindelin via GitGitGadget
                       ` (6 subsequent siblings)
  11 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-28 21:09 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Øystein Walle, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

By default, the build directory will be called something like
`contrib/buildsystems/out/build/x64-Debug (default)` (note the space and
the parentheses). We need to make sure that such a path is quoted
properly when editing the assignment of the `GIT_BUILD_DIR` variable.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index 683cf38263..1999db0c6b 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -949,7 +949,7 @@ if(NOT ${CMAKE_BINARY_DIR}/CMakeCache.txt STREQUAL ${CACHE_PATH})
 	file(WRITE ${CMAKE_BINARY_DIR}/CTestCustom.cmake
 		"file(STRINGS ${CMAKE_SOURCE_DIR}/t/test-lib.sh GIT_BUILD_DIR_REPL REGEX \"GIT_BUILD_DIR=(.*)\")\n"
 		"file(STRINGS ${CMAKE_SOURCE_DIR}/t/test-lib.sh content NEWLINE_CONSUME)\n"
-		"string(REPLACE \"\${GIT_BUILD_DIR_REPL}\" \"GIT_BUILD_DIR=\\\"$TEST_DIRECTORY\\\"/../${BUILD_DIR_RELATIVE}\" content \"\${content}\")\n"
+		"string(REPLACE \"\${GIT_BUILD_DIR_REPL}\" \"GIT_BUILD_DIR=\\\"$TEST_DIRECTORY/../${BUILD_DIR_RELATIVE}\\\"\" content \"\${content}\")\n"
 		"file(WRITE ${CMAKE_SOURCE_DIR}/t/test-lib.sh \${content})")
 	#misc copies
 	file(COPY ${CMAKE_SOURCE_DIR}/t/chainlint.sed DESTINATION ${CMAKE_BINARY_DIR}/t/)
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v3 06/11] cmake (Windows): let the `.dll` files be found when running the tests
  2020-09-28 21:09   ` [PATCH v3 00/11] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                       ` (4 preceding siblings ...)
  2020-09-28 21:09     ` [PATCH v3 05/11] cmake: quote the path accurately when editing `test-lib.sh` Johannes Schindelin via GitGitGadget
@ 2020-09-28 21:09     ` Johannes Schindelin via GitGitGadget
  2020-09-28 21:09     ` [PATCH v3 07/11] cmake (Windows): complain when encountering an unknown compiler Johannes Schindelin via GitGitGadget
                       ` (5 subsequent siblings)
  11 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-28 21:09 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Øystein Walle, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Contrary to Unix-ish platforms, the dependencies' shared libraries are
not usually found in one central place. In our case, since we use
`vcpkg`, they are to be found inside the `compat/vcbuild/vcpkg/` tree.

Let's make sure that they are in the search path when running the tests.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index 1999db0c6b..361fe3de6d 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -939,6 +939,9 @@ file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "X='${EXE_EXTENSION}'\n")
 file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "NO_GETTEXT='${NO_GETTEXT}'\n")
 file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "RUNTIME_PREFIX='${RUNTIME_PREFIX}'\n")
 file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "NO_PYTHON='${NO_PYTHON}'\n")
+if(WIN32)
+	file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "PATH=\"$PATH:$TEST_DIRECTORY/../compat/vcbuild/vcpkg/installed/x64-windows/bin\"\n")
+endif()
 
 #Make the tests work when building out of the source tree
 get_filename_component(CACHE_PATH ${CMAKE_CURRENT_LIST_DIR}/../../CMakeCache.txt ABSOLUTE)
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v3 07/11] cmake (Windows): complain when encountering an unknown compiler
  2020-09-28 21:09   ` [PATCH v3 00/11] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                       ` (5 preceding siblings ...)
  2020-09-28 21:09     ` [PATCH v3 06/11] cmake (Windows): let the `.dll` files be found when running the tests Johannes Schindelin via GitGitGadget
@ 2020-09-28 21:09     ` Johannes Schindelin via GitGitGadget
  2020-09-28 21:09     ` [PATCH v3 08/11] cmake (Windows): initialize vcpkg/build dependencies automatically Johannes Schindelin via GitGitGadget
                       ` (4 subsequent siblings)
  11 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-28 21:09 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Øystein Walle, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

We have some custom handling regarding the link options, which are
specific to each compiler.

Therefore: let's not just continue without setting the link options if
configuring for a currently unhandled compiler, but error out.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index 361fe3de6d..13d958f5a6 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -617,6 +617,8 @@ if(WIN32)
 		target_link_options(common-main PUBLIC -municode -Wl,-nxcompat -Wl,-dynamicbase -Wl,-entry:wmainCRTStartup -Wl,invalidcontinue.obj)
 	elseif(CMAKE_C_COMPILER_ID STREQUAL "MSVC")
 		target_link_options(common-main PUBLIC /IGNORE:4217 /IGNORE:4049 /NOLOGO /ENTRY:wmainCRTStartup /SUBSYSTEM:CONSOLE invalidcontinue.obj)
+	else()
+		message(FATAL_ERROR "Unhandled compiler: ${CMAKE_C_COMPILER_ID}")
 	endif()
 elseif(UNIX)
 	target_link_libraries(common-main pthread rt)
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v3 08/11] cmake (Windows): initialize vcpkg/build dependencies automatically
  2020-09-28 21:09   ` [PATCH v3 00/11] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                       ` (6 preceding siblings ...)
  2020-09-28 21:09     ` [PATCH v3 07/11] cmake (Windows): complain when encountering an unknown compiler Johannes Schindelin via GitGitGadget
@ 2020-09-28 21:09     ` Johannes Schindelin via GitGitGadget
  2020-09-29  6:51       ` Sibi Siddharthan
  2020-09-28 21:09     ` [PATCH v3 09/11] cmake (Windows): recommend using Visual Studio's built-in CMake support Johannes Schindelin via GitGitGadget
                       ` (3 subsequent siblings)
  11 siblings, 1 reply; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-28 21:09 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Øystein Walle, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The idea of having CMake support in Git's source tree is to enable
contributors on Windows to start contributing with little effort. To
that end, we just added some sensible defaults that will let users open
the worktree in Visual Studio and start building.

This expects the dependencies (such as zlib) to be available already,
though. If they are not available, we expect the user to run
`compat/vcbuild/vcpkg_install.bat`.

Rather than requiring this step to be manual, detect the situation and
run it as part of the CMake configuration step.

This concludes our journey to make it as effortless as possible to start
developing Git in Visual Studio: all the developer needs to do is to
clone Git's repository, open the worktree via `File>Open>Folder...` and
wait for CMake to finish configuring.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index 13d958f5a6..6a92ec9763 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -42,6 +42,10 @@ cmake_minimum_required(VERSION 3.14)
 set(CMAKE_SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/../..)
 if(WIN32)
 	set(VCPKG_DIR "${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg")
+	if(NOT EXISTS ${VCPKG_DIR})
+		message("Initializinge vcpkg and building the Git's dependencies (this will take a while...)")
+		execute_process(COMMAND ${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg_install.bat)
+	endif()
 	list(APPEND CMAKE_PREFIX_PATH "${VCPKG_DIR}/installed/x64-windows")
 
 	# In the vcpkg edition, we need this to be able to link to libcurl
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v3 09/11] cmake (Windows): recommend using Visual Studio's built-in CMake support
  2020-09-28 21:09   ` [PATCH v3 00/11] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                       ` (7 preceding siblings ...)
  2020-09-28 21:09     ` [PATCH v3 08/11] cmake (Windows): initialize vcpkg/build dependencies automatically Johannes Schindelin via GitGitGadget
@ 2020-09-28 21:09     ` Johannes Schindelin via GitGitGadget
  2020-09-28 21:09     ` [PATCH v3 10/11] hashmap_for_each_entry(): workaround MSVC's runtime check failure #3 Junio C Hamano via GitGitGadget
                       ` (2 subsequent siblings)
  11 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-28 21:09 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Øystein Walle, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

It is a lot more convenient to use than having to specify the
configuration in CMake manually (does not matter whether using the
command-line or CMake's GUI).

While at it, recommend using `contrib/buildsystems/out/` as build
directory also in the part that talks about running CMake manually.

Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 26 +++++++++++++++++---------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index 6a92ec9763..4b16744847 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -4,17 +4,25 @@
 
 #[[
 
-Instructions to run CMake:
+Instructions how to use this in Visual Studio:
 
-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
+Open the worktree as a folder. Visual Studio 2019 and later will detect
+the CMake configuration automatically and set everything up for you,
+ready to build. You can then run the tests in `t/` via a regular Git Bash.
 
-For out of source builds, say build in 'git/git-build/'
-	`mkdir git-build;cd git-build; cmake ../contrib/buildsystems/`
-This will build the git binaries in git-build directory
+Note: Visual Studio also has the option of opening `CMakeLists.txt`
+directly; Using this option, Visual Studio will not find the source code,
+though, therefore the `File>Open>Folder...` option is preferred.
+
+Instructions to run CMake manually:
+
+    mkdir -p contrib/buildsystems/out
+    cd contrib/buildsystems/out
+    cmake ../ -DCMAKE_BUILD_TYPE=Release
+
+This will build the git binaries in contrib/buildsystems/out
+directory (our top-level .gitignore file knows to ignore contents of
+this directory).
 
 Possible build configurations(-DCMAKE_BUILD_TYPE) with corresponding
 compiler flags
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v3 10/11] hashmap_for_each_entry(): workaround MSVC's runtime check failure #3
  2020-09-28 21:09   ` [PATCH v3 00/11] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                       ` (8 preceding siblings ...)
  2020-09-28 21:09     ` [PATCH v3 09/11] cmake (Windows): recommend using Visual Studio's built-in CMake support Johannes Schindelin via GitGitGadget
@ 2020-09-28 21:09     ` Junio C Hamano via GitGitGadget
  2020-09-28 21:09     ` [PATCH v3 11/11] cmake: fix typo in message when `msgfmt` was not found Johannes Schindelin via GitGitGadget
  2020-09-30 15:26     ` [PATCH v4 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
  11 siblings, 0 replies; 70+ messages in thread
From: Junio C Hamano via GitGitGadget @ 2020-09-28 21:09 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Øystein Walle, Johannes Schindelin, Junio C Hamano

From: Junio C Hamano <gitster@pobox.com>

The OFFSETOF_VAR(var, member) macro is implemented in terms of
offsetof(typeof(*var), member) with compilers that know typeof(),
but its fallback implemenation compares &(var->member) and (var) and
count the distance in bytes, i.e.

    ((uintptr_t)&(var)->member - (uintptr_t)(var))

MSVC's runtime check, when fed an uninitialized 'var', flags this as
a use of an uninitialized variable (and that is legit---uninitialized
contents of 'var' is subtracted) in a debug build.

After auditing all 6 uses of OFFSETOF_VAR(), 1 of them does feed a
potentially uninitialized 'var' to the macro in the beginning of the
for() loop:

    #define hashmap_for_each_entry(map, iter, var, member) \
            for (var = hashmap_iter_first_entry_offset(map, iter, \
                                                    OFFSETOF_VAR(var, member)); \
                    var; \
                    var = hashmap_iter_next_entry_offset(iter, \
                                                    OFFSETOF_VAR(var, member)))

We can work around this by making sure that var has _some_ value
when OFFSETOF_VAR() is called.  Strictly speaking, it invites
undefined behaviour to use NULL here if we end up with pointer
comparison, but MSVC runtime seems to be happy with it, and most
other systems have typeof() and don't even need pointer comparison
fallback code.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 hashmap.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hashmap.h b/hashmap.h
index ef220de4c6..b011b394fe 100644
--- a/hashmap.h
+++ b/hashmap.h
@@ -449,7 +449,8 @@ static inline struct hashmap_entry *hashmap_iter_first(struct hashmap *map,
  * containing a @member which is a "struct hashmap_entry"
  */
 #define hashmap_for_each_entry(map, iter, var, member) \
-	for (var = hashmap_iter_first_entry_offset(map, iter, \
+	for (var = NULL, /* for systems without typeof */ \
+	     var = hashmap_iter_first_entry_offset(map, iter, \
 						OFFSETOF_VAR(var, member)); \
 		var; \
 		var = hashmap_iter_next_entry_offset(iter, \
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v3 11/11] cmake: fix typo in message when `msgfmt` was not found
  2020-09-28 21:09   ` [PATCH v3 00/11] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                       ` (9 preceding siblings ...)
  2020-09-28 21:09     ` [PATCH v3 10/11] hashmap_for_each_entry(): workaround MSVC's runtime check failure #3 Junio C Hamano via GitGitGadget
@ 2020-09-28 21:09     ` Johannes Schindelin via GitGitGadget
  2020-09-28 22:11       ` Junio C Hamano
  2020-09-30 15:26     ` [PATCH v4 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
  11 siblings, 1 reply; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-28 21:09 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Øystein Walle, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index 4b16744847..b9fced682e 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -166,7 +166,7 @@ find_program(MSGFMT_EXE msgfmt)
 if(NOT MSGFMT_EXE)
 	set(MSGFMT_EXE ${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg/downloads/tools/msys2/msys64/usr/bin/msgfmt.exe)
 	if(NOT EXISTS ${MSGFMT_EXE})
-		message(WARNING "Text Translations won't be build")
+		message(WARNING "Text Translations won't be built")
 		unset(MSGFMT_EXE)
 	endif()
 endif()
-- 
gitgitgadget

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [PATCH v3 11/11] cmake: fix typo in message when `msgfmt` was not found
  2020-09-28 21:09     ` [PATCH v3 11/11] cmake: fix typo in message when `msgfmt` was not found Johannes Schindelin via GitGitGadget
@ 2020-09-28 22:11       ` Junio C Hamano
  2020-09-29 12:07         ` Johannes Schindelin
  0 siblings, 1 reply; 70+ messages in thread
From: Junio C Hamano @ 2020-09-28 22:11 UTC (permalink / raw)
  To: Johannes Schindelin via GitGitGadget
  Cc: git, Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Øystein Walle

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---

Shouldn't this be squashed into the step being fixed, which is part
of this series?  Would it be the "fall back to using..." step (4/11)?

>  contrib/buildsystems/CMakeLists.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
> index 4b16744847..b9fced682e 100644
> --- a/contrib/buildsystems/CMakeLists.txt
> +++ b/contrib/buildsystems/CMakeLists.txt
> @@ -166,7 +166,7 @@ find_program(MSGFMT_EXE msgfmt)
>  if(NOT MSGFMT_EXE)
>  	set(MSGFMT_EXE ${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg/downloads/tools/msys2/msys64/usr/bin/msgfmt.exe)
>  	if(NOT EXISTS ${MSGFMT_EXE})
> -		message(WARNING "Text Translations won't be build")
> +		message(WARNING "Text Translations won't be built")
>  		unset(MSGFMT_EXE)
>  	endif()
>  endif()

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [PATCH v3 08/11] cmake (Windows): initialize vcpkg/build dependencies automatically
  2020-09-28 21:09     ` [PATCH v3 08/11] cmake (Windows): initialize vcpkg/build dependencies automatically Johannes Schindelin via GitGitGadget
@ 2020-09-29  6:51       ` Sibi Siddharthan
  2020-09-29 12:07         ` Johannes Schindelin
  0 siblings, 1 reply; 70+ messages in thread
From: Sibi Siddharthan @ 2020-09-29  6:51 UTC (permalink / raw)
  To: Johannes Schindelin via GitGitGadget
  Cc: git, Đoàn Trần Công Danh, SZEDER Gábor,
	Eric Sunshine, Johannes Schindelin, Øystein Walle

>  if(WIN32)
>         set(VCPKG_DIR "${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg")
> +       if(NOT EXISTS ${VCPKG_DIR})
> +               message("Initializinge vcpkg and building the Git's dependencies (this will take a while...)")
         I think you meant Initializing. (Nitpicking :) )

Thank You,
Sibi Siddharthan

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [PATCH v3 08/11] cmake (Windows): initialize vcpkg/build dependencies automatically
  2020-09-29  6:51       ` Sibi Siddharthan
@ 2020-09-29 12:07         ` Johannes Schindelin
  0 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin @ 2020-09-29 12:07 UTC (permalink / raw)
  To: Sibi Siddharthan
  Cc: Johannes Schindelin via GitGitGadget, git,
	Đoàn Trần Công Danh, SZEDER Gábor,
	Eric Sunshine, Øystein Walle

Hi Sibi,

On Tue, 29 Sep 2020, Sibi Siddharthan wrote:

> >  if(WIN32)
> >         set(VCPKG_DIR "${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg")
> > +       if(NOT EXISTS ${VCPKG_DIR})
> > +               message("Initializinge vcpkg and building the Git's dependencies (this will take a while...)")
>          I think you meant Initializing. (Nitpicking :) )

Aw shucks! Thank you for being thorough,
Dscho

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [PATCH v3 11/11] cmake: fix typo in message when `msgfmt` was not found
  2020-09-28 22:11       ` Junio C Hamano
@ 2020-09-29 12:07         ` Johannes Schindelin
  0 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin @ 2020-09-29 12:07 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: Johannes Schindelin via GitGitGadget, git, Sibi Siddharthan,
	Đoàn Trần Công Danh, SZEDER Gábor,
	Eric Sunshine, Øystein Walle

Hi Junio,

On Mon, 28 Sep 2020, Junio C Hamano wrote:

> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
>
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
>
> Shouldn't this be squashed into the step being fixed, which is part
> of this series?  Would it be the "fall back to using..." step (4/11)?

Oy. I did not even realize that it was _my_ typo. Fixed in my branch. I'll
wait a little, just in case that anything else needs to be fixed, before
sending the next iteration.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [PATCH 02/10] cmake: do find Git for Windows' shell interpreter
  2020-09-28 13:56         ` Johannes Schindelin
@ 2020-09-29 14:04           ` Đoàn Trần Công Danh
  2020-09-29 18:42             ` Johannes Schindelin
  0 siblings, 1 reply; 70+ messages in thread
From: Đoàn Trần Công Danh @ 2020-09-29 14:04 UTC (permalink / raw)
  To: Johannes Schindelin
  Cc: Sibi Siddharthan, Johannes Schindelin via GitGitGadget, git,
	SZEDER Gábor

On 2020-09-28 15:56:13+0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi Danh,
> 
> On Sun, 27 Sep 2020, Đoàn Trần Công Danh wrote:
> 
> > On 2020-09-26 22:32:25+0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > > > I personally don't install my dev tools(except Visual Studio) to
> > > > Program Files(because of the _space_), it messes up the Makefiles.
> > >
> > > Sure, and that's your prerogative. There's unfortunately no good way to
> > > support your use case.
> > >
> > > Luckily, the vast majority of Git for Windows' users do not change the
> > > default location, and this patch is for them. (And "them" in this case
> > > includes me, personally ;-))
> >
> > This doesn't fit into my view of Git for Windows' users
> > For some users that have the Administrator right, it's the default
> > location if they grant the Administrator right for the installer.
> >
> > For those poor souls that works for enterprise companies, and thoses
> > that not feel comfortable give Administrator right to _another_
> > installer, the installer will install into (hopeful, I type it right):
> >
> > 	%USERPROFILE%/AppData/Local/Programs/Git
> 
> Those poor souls that work for enterprise companies often have Git for
> Windows installed by default. And of course, that default would be in
> `C:\Program Files\Git`.

Yes, that's correct, but that Git is usually very old, and I'm not
sure about its layout. Obviously, you know better in this regard :-p

> 
> > I think it's better to offer SH_EXE as an OPTION, let user specify it
> > as will. And we'll search in PATH if it's not specified, fallback to
> > 2 default value if not found.
> 
> That's exactly as it is right now. You can specify `SH_EXE` (but only if
> running CMake manually, not via Visual Studio). If you don't, it searches
> `PATH`, and with my patch it then falls back to trying to find `sh.exe` in
> Git for Windows' default location.
> 
> So I think we're in agreement here?

Yes, seems good.

-- 
Danh

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [PATCH 02/10] cmake: do find Git for Windows' shell interpreter
  2020-09-29 14:04           ` Đoàn Trần Công Danh
@ 2020-09-29 18:42             ` Johannes Schindelin
  0 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin @ 2020-09-29 18:42 UTC (permalink / raw)
  To: Đoàn Trần Công Danh
  Cc: Sibi Siddharthan, Johannes Schindelin via GitGitGadget, git,
	SZEDER Gábor

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

Hi Danh,

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

> On 2020-09-28 15:56:13+0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > On Sun, 27 Sep 2020, Đoàn Trần Công Danh wrote:
> >
> > > On 2020-09-26 22:32:25+0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > >
> > > > > I personally don't install my dev tools(except Visual Studio) to
> > > > > Program Files(because of the _space_), it messes up the Makefiles.
> > > >
> > > > Sure, and that's your prerogative. There's unfortunately no good way to
> > > > support your use case.
> > > >
> > > > Luckily, the vast majority of Git for Windows' users do not change the
> > > > default location, and this patch is for them. (And "them" in this case
> > > > includes me, personally ;-))
> > >
> > > This doesn't fit into my view of Git for Windows' users
> > > For some users that have the Administrator right, it's the default
> > > location if they grant the Administrator right for the installer.
> > >
> > > For those poor souls that works for enterprise companies, and thoses
> > > that not feel comfortable give Administrator right to _another_
> > > installer, the installer will install into (hopeful, I type it right):
> > >
> > > 	%USERPROFILE%/AppData/Local/Programs/Git
> >
> > Those poor souls that work for enterprise companies often have Git for
> > Windows installed by default. And of course, that default would be in
> > `C:\Program Files\Git`.
>
> Yes, that's correct, but that Git is usually very old, and I'm not
> sure about its layout. Obviously, you know better in this regard :-p

In Git for Windows v1.x, it would have contained the real Bash (at least
in 32-bit Windows; in 64-bit Windows, it would have been `C:\Program Files
(x86)\Git\bin`). But v1.x is long deprecated, it's over 5 years old.

The `C:\Program Files\Git\bin\sh.exe` stand-in is actually not _all_ that
old, I only reintroduced it relatively recently. Nevertheless, it is the
best bet for a default fall-back that I can think of.

> > > I think it's better to offer SH_EXE as an OPTION, let user specify it
> > > as will. And we'll search in PATH if it's not specified, fallback to
> > > 2 default value if not found.
> >
> > That's exactly as it is right now. You can specify `SH_EXE` (but only if
> > running CMake manually, not via Visual Studio). If you don't, it searches
> > `PATH`, and with my patch it then falls back to trying to find `sh.exe` in
> > Git for Windows' default location.
> >
> > So I think we're in agreement here?
>
> Yes, seems good.

Excellent!
Dscho

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [PATCH 08/10] cmake (Windows): initialize vcpkg/build dependencies automatically
  2020-09-25 14:28 ` [PATCH 08/10] cmake (Windows): initialize vcpkg/build dependencies automatically Johannes Schindelin via GitGitGadget
@ 2020-09-30  5:05   ` Sibi Siddharthan
  2020-09-30 15:25     ` Johannes Schindelin
  0 siblings, 1 reply; 70+ messages in thread
From: Sibi Siddharthan @ 2020-09-30  5:05 UTC (permalink / raw)
  To: Johannes Schindelin via GitGitGadget
  Cc: git, Đoàn Trần Công Danh, SZEDER Gábor,
	Johannes Schindelin

On Fri, Sep 25, 2020 at 7:58 PM Johannes Schindelin via GitGitGadget
<gitgitgadget@gmail.com> wrote:
>
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> The idea of having CMake support in Git's source tree is to enable
> contributors on Windows to start contributing with little effort. To
> that end, we just added some sensible defaults that will let users open
> the worktree in Visual Studio and start building.
>
> This expects the dependencies (such as zlib) to be available already,
> though. If they are not available, we expect the user to run
> `compat/vcbuild/vcpkg_install.bat`.
>
> Rather than requiring this step to be manual, detect the situation and
> run it as part of the CMake configuration step.
>
> This concludes our journey to make it as effortless as possible to start
> developing Git in Visual Studio: all the developer needs to do is to
> clone Git's repository, open the worktree via `File>Open>Folder...` and
> wait for CMake to finish configuring.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>  contrib/buildsystems/CMakeLists.txt | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
> index d21849b730..1eaeb8b8e0 100644
> --- a/contrib/buildsystems/CMakeLists.txt
> +++ b/contrib/buildsystems/CMakeLists.txt
> @@ -42,6 +42,10 @@ cmake_minimum_required(VERSION 3.14)
>  set(CMAKE_SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/../..)
>  if(WIN32)
>         set(VCPKG_DIR "${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg")
> +       if(NOT EXISTS ${VCPKG_DIR})
> +               message("Initializinge vcpkg and building the Git's dependencies (this will take a while...)")
> +               execute_process(COMMAND ${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg_install.bat)
> +       endif()
>         list(APPEND CMAKE_PREFIX_PATH "${VCPKG_DIR}/installed/x64-windows")
>
>         # In the vcpkg edition, we need this to be able to link to libcurl
> --
> gitgitgadget
>

After reading the patch series I seem to get to feeling that people on
Windows are being nudged to use Visual Studio and vcpkg.
Although they are great tools, when I want to specify my own libraries
I don't see an option here.
I think we need to define a variable, which this conditional block
uses, which is set to true if we are using a Visual Studio Generator.
We also need a way to override this option if needed.
If this variable(explained above) is not set or false or OFF, we defer
building vcpkg libraries. This can also save time in the case
when we already have the dependencies(libraries) and just want to
point to them instead of building with vcpkg.
I also see that people who use gcc(MinGW) are left out. I think we
also need to set the supported compiler(s) here before executing
vcpkg_install.bat. People who use gcc would need to point to their own
libraries with CMAKE_PREFIX_PATH.

Thank You,
Sibi Siddharthan

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [PATCH 08/10] cmake (Windows): initialize vcpkg/build dependencies automatically
  2020-09-30  5:05   ` Sibi Siddharthan
@ 2020-09-30 15:25     ` Johannes Schindelin
  0 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin @ 2020-09-30 15:25 UTC (permalink / raw)
  To: Sibi Siddharthan
  Cc: Johannes Schindelin via GitGitGadget, git,
	Đoàn Trần Công Danh, SZEDER Gábor

Hi Sibi,

On Wed, 30 Sep 2020, Sibi Siddharthan wrote:

> On Fri, Sep 25, 2020 at 7:58 PM Johannes Schindelin via GitGitGadget
> <gitgitgadget@gmail.com> wrote:
> >
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > The idea of having CMake support in Git's source tree is to enable
> > contributors on Windows to start contributing with little effort. To
> > that end, we just added some sensible defaults that will let users open
> > the worktree in Visual Studio and start building.
> >
> > This expects the dependencies (such as zlib) to be available already,
> > though. If they are not available, we expect the user to run
> > `compat/vcbuild/vcpkg_install.bat`.
> >
> > Rather than requiring this step to be manual, detect the situation and
> > run it as part of the CMake configuration step.
> >
> > This concludes our journey to make it as effortless as possible to start
> > developing Git in Visual Studio: all the developer needs to do is to
> > clone Git's repository, open the worktree via `File>Open>Folder...` and
> > wait for CMake to finish configuring.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >  contrib/buildsystems/CMakeLists.txt | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
> > index d21849b730..1eaeb8b8e0 100644
> > --- a/contrib/buildsystems/CMakeLists.txt
> > +++ b/contrib/buildsystems/CMakeLists.txt
> > @@ -42,6 +42,10 @@ cmake_minimum_required(VERSION 3.14)
> >  set(CMAKE_SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/../..)
> >  if(WIN32)
> >         set(VCPKG_DIR "${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg")
> > +       if(NOT EXISTS ${VCPKG_DIR})
> > +               message("Initializinge vcpkg and building the Git's dependencies (this will take a while...)")
> > +               execute_process(COMMAND ${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg_install.bat)
> > +       endif()
> >         list(APPEND CMAKE_PREFIX_PATH "${VCPKG_DIR}/installed/x64-windows")
> >
> >         # In the vcpkg edition, we need this to be able to link to libcurl
> > --
> > gitgitgadget
> >
>
> After reading the patch series I seem to get to feeling that people on
> Windows are being nudged to use Visual Studio and vcpkg.
> Although they are great tools, when I want to specify my own libraries
> I don't see an option here.
> I think we need to define a variable, which this conditional block
> uses, which is set to true if we are using a Visual Studio Generator.
> We also need a way to override this option if needed.
> If this variable(explained above) is not set or false or OFF, we defer
> building vcpkg libraries. This can also save time in the case
> when we already have the dependencies(libraries) and just want to
> point to them instead of building with vcpkg.
> I also see that people who use gcc(MinGW) are left out. I think we
> also need to set the supported compiler(s) here before executing
> vcpkg_install.bat. People who use gcc would need to point to their own
> libraries with CMAKE_PREFIX_PATH.

Good points, even if our current CMake push really tries to cater only to
Visual Studio (or at least, MS Visual C) users.

I added a further guard to the conditional: `MSVC` needs to be true. This
makes sense, as our current support for MSVC/Visual Studio hinges on
having vcpkg build the dependencies, we simply do not support anything
else. (And it would be easy enough for a proficient Visual Studio user to
_still_ override the vcpkg system with their own libraries, if they
really want to make that work.)

Thanks,
Dscho

^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v4 00/10] CMake and Visual Studio
  2020-09-28 21:09   ` [PATCH v3 00/11] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                       ` (10 preceding siblings ...)
  2020-09-28 21:09     ` [PATCH v3 11/11] cmake: fix typo in message when `msgfmt` was not found Johannes Schindelin via GitGitGadget
@ 2020-09-30 15:26     ` Johannes Schindelin via GitGitGadget
  2020-09-30 15:26       ` [PATCH v4 01/10] cmake: ignore files generated by CMake as run in " Johannes Schindelin via GitGitGadget
                         ` (9 more replies)
  11 siblings, 10 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-30 15:26 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Øystein Walle, Johannes Schindelin

The intention of this patch series is to make it as easy as possible for a
Visual Studio user to start building Git from scratch. The idea is to

 * clone Git's source code,
 * open it in Visual Studio via File>Open>Folder...
 * let CMake configure things (and vcpkg build the dependencies, which will
   take a while), and
 * start the build.

It does require a Git for Windows to be installed so that the source can be
cloned, but also to run the shell script parts of the CMake configuration,
and also to run the tests.

This patch series replaces the patch "Ignore files generated by CMake" I
sent via https://github.com/gitgitgadget/git/pull/735.

Changes since v3:

 * Squashed the typo fix into the correct commit (d'oh!)
 * Fixed another typo (thanks, Sibi!)
 * Guarded the code block that initializes vcpkg and builds the dependencies
   behind the MSVC conditional (thanks, Sibi!)

Changes since v2:

 * Fixed a typo in the message when msgfmt.exe is not found.
 * Simplified the logic to find sh.exe (thanks Øystein).

Changes since v1:

 * Touched up a couple commit messages in response to reviewer comments
 * Adjusted the instructions at the top of CMakeLists.txt so that the part
   talking about running CMake manually also talks about using 
   contrib/buildsystems/out/ as build directory (in line with the part
   talking about Visual Studio's out-of-the-box experience)
 * Replaced patch 10/10 with Junio's much more elegant solution of editing
   the hashmap_for_each_entry() macro instead of all of its callers.

Johannes Schindelin (9):
  cmake: ignore files generated by CMake as run in Visual Studio
  cmake: do find Git for Windows' shell interpreter
  cmake: ensure that the `vcpkg` packages are found on Windows
  cmake: fall back to using `vcpkg`'s `msgfmt.exe` on Windows
  cmake: quote the path accurately when editing `test-lib.sh`
  cmake (Windows): let the `.dll` files be found when running the tests
  cmake (Windows): complain when encountering an unknown compiler
  cmake (Windows): initialize vcpkg/build dependencies automatically
  cmake (Windows): recommend using Visual Studio's built-in CMake
    support

Junio C Hamano (1):
  hashmap_for_each_entry(): workaround MSVC's runtime check failure #3

 .gitignore                          |  1 +
 contrib/buildsystems/CMakeLists.txt | 52 ++++++++++++++++++++++-------
 hashmap.h                           |  3 +-
 3 files changed, 43 insertions(+), 13 deletions(-)


base-commit: 9bc233ae1cf19a49e51842c7959d80a675dbd1c0
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-738%2Fdscho%2Fcmake-and-visual-studio-v4
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-738/dscho/cmake-and-visual-studio-v4
Pull-Request: https://github.com/gitgitgadget/git/pull/738

Range-diff vs v3:

  1:  9c7a964519 =  1:  9c7a964519 cmake: ignore files generated by CMake as run in Visual Studio
  2:  3b467360bb =  2:  3b467360bb cmake: do find Git for Windows' shell interpreter
  3:  a49b28e001 =  3:  a49b28e001 cmake: ensure that the `vcpkg` packages are found on Windows
  4:  f1baf0f974 !  4:  56cfdb2ee9 cmake: fall back to using `vcpkg`'s `msgfmt.exe` on Windows
     @@ contrib/buildsystems/CMakeLists.txt: endif()
      -	message(WARNING "Text Translations won't be build")
      +	set(MSGFMT_EXE ${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg/downloads/tools/msys2/msys64/usr/bin/msgfmt.exe)
      +	if(NOT EXISTS ${MSGFMT_EXE})
     -+		message(WARNING "Text Translations won't be build")
     ++		message(WARNING "Text Translations won't be built")
      +		unset(MSGFMT_EXE)
      +	endif()
       endif()
  5:  8380aa55ab =  5:  cfedb1673a cmake: quote the path accurately when editing `test-lib.sh`
  6:  f61c3ef442 =  6:  d402f721c2 cmake (Windows): let the `.dll` files be found when running the tests
  7:  7a4346a437 =  7:  0e7fdfddb4 cmake (Windows): complain when encountering an unknown compiler
  8:  7c1601c7e3 !  8:  14ddfc1781 cmake (Windows): initialize vcpkg/build dependencies automatically
     @@ Commit message
          Rather than requiring this step to be manual, detect the situation and
          run it as part of the CMake configuration step.
      
     +    Note that this obviously only applies to the scenario when we want to
     +    compile in Visual Studio (i.e. with MS Visual C), not with GCC.
     +    Therefore, we guard this new code block behind the `MSVC` conditional.
     +
          This concludes our journey to make it as effortless as possible to start
          developing Git in Visual Studio: all the developer needs to do is to
          clone Git's repository, open the worktree via `File>Open>Folder...` and
     @@ Commit message
      
          Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
      
     +    squash! cmake (Windows): initialize vcpkg/build dependencies automatically
     +
     +    MSVC
     +
       ## contrib/buildsystems/CMakeLists.txt ##
      @@ contrib/buildsystems/CMakeLists.txt: cmake_minimum_required(VERSION 3.14)
       set(CMAKE_SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/../..)
       if(WIN32)
       	set(VCPKG_DIR "${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg")
     -+	if(NOT EXISTS ${VCPKG_DIR})
     -+		message("Initializinge vcpkg and building the Git's dependencies (this will take a while...)")
     ++	if(MSVC AND NOT EXISTS ${VCPKG_DIR})
     ++		message("Initializing vcpkg and building the Git's dependencies (this will take a while...)")
      +		execute_process(COMMAND ${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg_install.bat)
      +	endif()
       	list(APPEND CMAKE_PREFIX_PATH "${VCPKG_DIR}/installed/x64-windows")
  9:  ec182738f0 =  9:  b239162eb2 cmake (Windows): recommend using Visual Studio's built-in CMake support
 10:  38cef4deb5 = 10:  7643a766b7 hashmap_for_each_entry(): workaround MSVC's runtime check failure #3
 11:  c3e235fe39 <  -:  ---------- cmake: fix typo in message when `msgfmt` was not found

-- 
gitgitgadget

^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v4 01/10] cmake: ignore files generated by CMake as run in Visual Studio
  2020-09-30 15:26     ` [PATCH v4 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
@ 2020-09-30 15:26       ` Johannes Schindelin via GitGitGadget
  2020-09-30 15:26       ` [PATCH v4 02/10] cmake: do find Git for Windows' shell interpreter Johannes Schindelin via GitGitGadget
                         ` (8 subsequent siblings)
  9 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-30 15:26 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Øystein Walle, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

As of recent Visual Studio versions, CMake support is built-in:
https://docs.microsoft.com/en-us/cpp/build/cmake-projects-in-visual-studio?view=vs-2019

All that needs to be done is to open the worktree as a folder, and
Visual Studio will find the `CMakeLists.txt` file and automatically
generate the project files.

Let's ignore the entirety of those generated files.

Helped-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index 800b812c6a..6232d33924 100644
--- a/.gitignore
+++ b/.gitignore
@@ -242,3 +242,4 @@ Release/
 /git.VC.VC.opendb
 /git.VC.db
 *.dSYM
+/contrib/buildsystems/out
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v4 02/10] cmake: do find Git for Windows' shell interpreter
  2020-09-30 15:26     ` [PATCH v4 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
  2020-09-30 15:26       ` [PATCH v4 01/10] cmake: ignore files generated by CMake as run in " Johannes Schindelin via GitGitGadget
@ 2020-09-30 15:26       ` Johannes Schindelin via GitGitGadget
  2020-09-30 15:26       ` [PATCH v4 03/10] cmake: ensure that the `vcpkg` packages are found on Windows Johannes Schindelin via GitGitGadget
                         ` (7 subsequent siblings)
  9 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-30 15:26 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Øystein Walle, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

By default, Git for Windows does not install its `sh.exe` into the
`PATH`. However, our current `CMakeLists.txt` expects to find a shell
interpreter in the `PATH`.

So let's fall back to looking in the default location where Git for
Windows _does_ install a relatively convenient `sh.exe`:
`C:\Program Files\Git\bin\sh.exe`

Helped-by: Øystein Walle <oystwa@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index 5007f173f1..1847a6fd58 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -41,7 +41,7 @@ cmake_minimum_required(VERSION 3.14)
 #set the source directory to root of git
 set(CMAKE_SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/../..)
 
-find_program(SH_EXE sh)
+find_program(SH_EXE sh PATHS "C:/Program Files/Git/bin")
 if(NOT SH_EXE)
 	message(FATAL_ERROR "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/")
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v4 03/10] cmake: ensure that the `vcpkg` packages are found on Windows
  2020-09-30 15:26     ` [PATCH v4 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
  2020-09-30 15:26       ` [PATCH v4 01/10] cmake: ignore files generated by CMake as run in " Johannes Schindelin via GitGitGadget
  2020-09-30 15:26       ` [PATCH v4 02/10] cmake: do find Git for Windows' shell interpreter Johannes Schindelin via GitGitGadget
@ 2020-09-30 15:26       ` Johannes Schindelin via GitGitGadget
  2020-09-30 15:26       ` [PATCH v4 04/10] cmake: fall back to using `vcpkg`'s `msgfmt.exe` " Johannes Schindelin via GitGitGadget
                         ` (6 subsequent siblings)
  9 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-30 15:26 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Øystein Walle, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

On Windows, we use the `vcpkg` project to manage the dependencies, via
`compat/vcbuild/`. Let's make sure that these dependencies are found by
default.

This is needed because we are about to recommend loading the Git
worktree as a folder into Visual Studio, relying on the automatic CMake
support (which would make it relatively cumbersome to adjust the search
path used by CMake manually).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index 1847a6fd58..12268f61ba 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -40,6 +40,13 @@ cmake_minimum_required(VERSION 3.14)
 
 #set the source directory to root of git
 set(CMAKE_SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/../..)
+if(WIN32)
+	set(VCPKG_DIR "${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg")
+	list(APPEND CMAKE_PREFIX_PATH "${VCPKG_DIR}/installed/x64-windows")
+
+	# In the vcpkg edition, we need this to be able to link to libcurl
+	set(CURL_NO_CURL_CMAKE ON)
+endif()
 
 find_program(SH_EXE sh PATHS "C:/Program Files/Git/bin")
 if(NOT SH_EXE)
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v4 04/10] cmake: fall back to using `vcpkg`'s `msgfmt.exe` on Windows
  2020-09-30 15:26     ` [PATCH v4 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                         ` (2 preceding siblings ...)
  2020-09-30 15:26       ` [PATCH v4 03/10] cmake: ensure that the `vcpkg` packages are found on Windows Johannes Schindelin via GitGitGadget
@ 2020-09-30 15:26       ` Johannes Schindelin via GitGitGadget
  2020-09-30 15:26       ` [PATCH v4 05/10] cmake: quote the path accurately when editing `test-lib.sh` Johannes Schindelin via GitGitGadget
                         ` (5 subsequent siblings)
  9 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-30 15:26 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Øystein Walle, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

We are already relying on `vcpkg` to manage our dependencies, including
`libiconv`. Let's also use the `msgfmt.exe` from there.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index 12268f61ba..02241dcc77 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -152,7 +152,11 @@ endif()
 
 find_program(MSGFMT_EXE msgfmt)
 if(NOT MSGFMT_EXE)
-	message(WARNING "Text Translations won't be build")
+	set(MSGFMT_EXE ${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg/downloads/tools/msys2/msys64/usr/bin/msgfmt.exe)
+	if(NOT EXISTS ${MSGFMT_EXE})
+		message(WARNING "Text Translations won't be built")
+		unset(MSGFMT_EXE)
+	endif()
 endif()
 
 #Force all visual studio outputs to CMAKE_BINARY_DIR
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v4 05/10] cmake: quote the path accurately when editing `test-lib.sh`
  2020-09-30 15:26     ` [PATCH v4 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                         ` (3 preceding siblings ...)
  2020-09-30 15:26       ` [PATCH v4 04/10] cmake: fall back to using `vcpkg`'s `msgfmt.exe` " Johannes Schindelin via GitGitGadget
@ 2020-09-30 15:26       ` Johannes Schindelin via GitGitGadget
  2020-09-30 15:26       ` [PATCH v4 06/10] cmake (Windows): let the `.dll` files be found when running the tests Johannes Schindelin via GitGitGadget
                         ` (4 subsequent siblings)
  9 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-30 15:26 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Øystein Walle, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

By default, the build directory will be called something like
`contrib/buildsystems/out/build/x64-Debug (default)` (note the space and
the parentheses). We need to make sure that such a path is quoted
properly when editing the assignment of the `GIT_BUILD_DIR` variable.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index 02241dcc77..3bb74337e1 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -949,7 +949,7 @@ if(NOT ${CMAKE_BINARY_DIR}/CMakeCache.txt STREQUAL ${CACHE_PATH})
 	file(WRITE ${CMAKE_BINARY_DIR}/CTestCustom.cmake
 		"file(STRINGS ${CMAKE_SOURCE_DIR}/t/test-lib.sh GIT_BUILD_DIR_REPL REGEX \"GIT_BUILD_DIR=(.*)\")\n"
 		"file(STRINGS ${CMAKE_SOURCE_DIR}/t/test-lib.sh content NEWLINE_CONSUME)\n"
-		"string(REPLACE \"\${GIT_BUILD_DIR_REPL}\" \"GIT_BUILD_DIR=\\\"$TEST_DIRECTORY\\\"/../${BUILD_DIR_RELATIVE}\" content \"\${content}\")\n"
+		"string(REPLACE \"\${GIT_BUILD_DIR_REPL}\" \"GIT_BUILD_DIR=\\\"$TEST_DIRECTORY/../${BUILD_DIR_RELATIVE}\\\"\" content \"\${content}\")\n"
 		"file(WRITE ${CMAKE_SOURCE_DIR}/t/test-lib.sh \${content})")
 	#misc copies
 	file(COPY ${CMAKE_SOURCE_DIR}/t/chainlint.sed DESTINATION ${CMAKE_BINARY_DIR}/t/)
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v4 06/10] cmake (Windows): let the `.dll` files be found when running the tests
  2020-09-30 15:26     ` [PATCH v4 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                         ` (4 preceding siblings ...)
  2020-09-30 15:26       ` [PATCH v4 05/10] cmake: quote the path accurately when editing `test-lib.sh` Johannes Schindelin via GitGitGadget
@ 2020-09-30 15:26       ` Johannes Schindelin via GitGitGadget
  2020-09-30 15:26       ` [PATCH v4 07/10] cmake (Windows): complain when encountering an unknown compiler Johannes Schindelin via GitGitGadget
                         ` (3 subsequent siblings)
  9 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-30 15:26 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Øystein Walle, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Contrary to Unix-ish platforms, the dependencies' shared libraries are
not usually found in one central place. In our case, since we use
`vcpkg`, they are to be found inside the `compat/vcbuild/vcpkg/` tree.

Let's make sure that they are in the search path when running the tests.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index 3bb74337e1..55d0960002 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -939,6 +939,9 @@ file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "X='${EXE_EXTENSION}'\n")
 file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "NO_GETTEXT='${NO_GETTEXT}'\n")
 file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "RUNTIME_PREFIX='${RUNTIME_PREFIX}'\n")
 file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "NO_PYTHON='${NO_PYTHON}'\n")
+if(WIN32)
+	file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "PATH=\"$PATH:$TEST_DIRECTORY/../compat/vcbuild/vcpkg/installed/x64-windows/bin\"\n")
+endif()
 
 #Make the tests work when building out of the source tree
 get_filename_component(CACHE_PATH ${CMAKE_CURRENT_LIST_DIR}/../../CMakeCache.txt ABSOLUTE)
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v4 07/10] cmake (Windows): complain when encountering an unknown compiler
  2020-09-30 15:26     ` [PATCH v4 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                         ` (5 preceding siblings ...)
  2020-09-30 15:26       ` [PATCH v4 06/10] cmake (Windows): let the `.dll` files be found when running the tests Johannes Schindelin via GitGitGadget
@ 2020-09-30 15:26       ` Johannes Schindelin via GitGitGadget
  2020-09-30 15:26       ` [PATCH v4 08/10] cmake (Windows): initialize vcpkg/build dependencies automatically Johannes Schindelin via GitGitGadget
                         ` (2 subsequent siblings)
  9 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-30 15:26 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Øystein Walle, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

We have some custom handling regarding the link options, which are
specific to each compiler.

Therefore: let's not just continue without setting the link options if
configuring for a currently unhandled compiler, but error out.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index 55d0960002..78b90abe5e 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -617,6 +617,8 @@ if(WIN32)
 		target_link_options(common-main PUBLIC -municode -Wl,-nxcompat -Wl,-dynamicbase -Wl,-entry:wmainCRTStartup -Wl,invalidcontinue.obj)
 	elseif(CMAKE_C_COMPILER_ID STREQUAL "MSVC")
 		target_link_options(common-main PUBLIC /IGNORE:4217 /IGNORE:4049 /NOLOGO /ENTRY:wmainCRTStartup /SUBSYSTEM:CONSOLE invalidcontinue.obj)
+	else()
+		message(FATAL_ERROR "Unhandled compiler: ${CMAKE_C_COMPILER_ID}")
 	endif()
 elseif(UNIX)
 	target_link_libraries(common-main pthread rt)
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v4 08/10] cmake (Windows): initialize vcpkg/build dependencies automatically
  2020-09-30 15:26     ` [PATCH v4 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                         ` (6 preceding siblings ...)
  2020-09-30 15:26       ` [PATCH v4 07/10] cmake (Windows): complain when encountering an unknown compiler Johannes Schindelin via GitGitGadget
@ 2020-09-30 15:26       ` Johannes Schindelin via GitGitGadget
  2020-09-30 19:17         ` Johannes Schindelin
  2020-09-30 15:26       ` [PATCH v4 09/10] cmake (Windows): recommend using Visual Studio's built-in CMake support Johannes Schindelin via GitGitGadget
  2020-09-30 15:26       ` [PATCH v4 10/10] hashmap_for_each_entry(): workaround MSVC's runtime check failure #3 Junio C Hamano via GitGitGadget
  9 siblings, 1 reply; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-30 15:26 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Øystein Walle, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The idea of having CMake support in Git's source tree is to enable
contributors on Windows to start contributing with little effort. To
that end, we just added some sensible defaults that will let users open
the worktree in Visual Studio and start building.

This expects the dependencies (such as zlib) to be available already,
though. If they are not available, we expect the user to run
`compat/vcbuild/vcpkg_install.bat`.

Rather than requiring this step to be manual, detect the situation and
run it as part of the CMake configuration step.

Note that this obviously only applies to the scenario when we want to
compile in Visual Studio (i.e. with MS Visual C), not with GCC.
Therefore, we guard this new code block behind the `MSVC` conditional.

This concludes our journey to make it as effortless as possible to start
developing Git in Visual Studio: all the developer needs to do is to
clone Git's repository, open the worktree via `File>Open>Folder...` and
wait for CMake to finish configuring.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

squash! cmake (Windows): initialize vcpkg/build dependencies automatically

MSVC
---
 contrib/buildsystems/CMakeLists.txt | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index 78b90abe5e..ebadae2271 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -42,6 +42,10 @@ cmake_minimum_required(VERSION 3.14)
 set(CMAKE_SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/../..)
 if(WIN32)
 	set(VCPKG_DIR "${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg")
+	if(MSVC AND NOT EXISTS ${VCPKG_DIR})
+		message("Initializing vcpkg and building the Git's dependencies (this will take a while...)")
+		execute_process(COMMAND ${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg_install.bat)
+	endif()
 	list(APPEND CMAKE_PREFIX_PATH "${VCPKG_DIR}/installed/x64-windows")
 
 	# In the vcpkg edition, we need this to be able to link to libcurl
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v4 09/10] cmake (Windows): recommend using Visual Studio's built-in CMake support
  2020-09-30 15:26     ` [PATCH v4 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                         ` (7 preceding siblings ...)
  2020-09-30 15:26       ` [PATCH v4 08/10] cmake (Windows): initialize vcpkg/build dependencies automatically Johannes Schindelin via GitGitGadget
@ 2020-09-30 15:26       ` Johannes Schindelin via GitGitGadget
  2020-09-30 15:26       ` [PATCH v4 10/10] hashmap_for_each_entry(): workaround MSVC's runtime check failure #3 Junio C Hamano via GitGitGadget
  9 siblings, 0 replies; 70+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-30 15:26 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Øystein Walle, Johannes Schindelin, Johannes Schindelin

From: Johannes Schindelin <johannes.schindelin@gmx.de>

It is a lot more convenient to use than having to specify the
configuration in CMake manually (does not matter whether using the
command-line or CMake's GUI).

While at it, recommend using `contrib/buildsystems/out/` as build
directory also in the part that talks about running CMake manually.

Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 contrib/buildsystems/CMakeLists.txt | 26 +++++++++++++++++---------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index ebadae2271..df539a44fa 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -4,17 +4,25 @@
 
 #[[
 
-Instructions to run CMake:
+Instructions how to use this in Visual Studio:
 
-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
+Open the worktree as a folder. Visual Studio 2019 and later will detect
+the CMake configuration automatically and set everything up for you,
+ready to build. You can then run the tests in `t/` via a regular Git Bash.
 
-For out of source builds, say build in 'git/git-build/'
-	`mkdir git-build;cd git-build; cmake ../contrib/buildsystems/`
-This will build the git binaries in git-build directory
+Note: Visual Studio also has the option of opening `CMakeLists.txt`
+directly; Using this option, Visual Studio will not find the source code,
+though, therefore the `File>Open>Folder...` option is preferred.
+
+Instructions to run CMake manually:
+
+    mkdir -p contrib/buildsystems/out
+    cd contrib/buildsystems/out
+    cmake ../ -DCMAKE_BUILD_TYPE=Release
+
+This will build the git binaries in contrib/buildsystems/out
+directory (our top-level .gitignore file knows to ignore contents of
+this directory).
 
 Possible build configurations(-DCMAKE_BUILD_TYPE) with corresponding
 compiler flags
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 70+ messages in thread

* [PATCH v4 10/10] hashmap_for_each_entry(): workaround MSVC's runtime check failure #3
  2020-09-30 15:26     ` [PATCH v4 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
                         ` (8 preceding siblings ...)
  2020-09-30 15:26       ` [PATCH v4 09/10] cmake (Windows): recommend using Visual Studio's built-in CMake support Johannes Schindelin via GitGitGadget
@ 2020-09-30 15:26       ` Junio C Hamano via GitGitGadget
  9 siblings, 0 replies; 70+ messages in thread
From: Junio C Hamano via GitGitGadget @ 2020-09-30 15:26 UTC (permalink / raw)
  To: git
  Cc: Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Johannes Schindelin,
	Øystein Walle, Johannes Schindelin, Junio C Hamano

From: Junio C Hamano <gitster@pobox.com>

The OFFSETOF_VAR(var, member) macro is implemented in terms of
offsetof(typeof(*var), member) with compilers that know typeof(),
but its fallback implemenation compares &(var->member) and (var) and
count the distance in bytes, i.e.

    ((uintptr_t)&(var)->member - (uintptr_t)(var))

MSVC's runtime check, when fed an uninitialized 'var', flags this as
a use of an uninitialized variable (and that is legit---uninitialized
contents of 'var' is subtracted) in a debug build.

After auditing all 6 uses of OFFSETOF_VAR(), 1 of them does feed a
potentially uninitialized 'var' to the macro in the beginning of the
for() loop:

    #define hashmap_for_each_entry(map, iter, var, member) \
            for (var = hashmap_iter_first_entry_offset(map, iter, \
                                                    OFFSETOF_VAR(var, member)); \
                    var; \
                    var = hashmap_iter_next_entry_offset(iter, \
                                                    OFFSETOF_VAR(var, member)))

We can work around this by making sure that var has _some_ value
when OFFSETOF_VAR() is called.  Strictly speaking, it invites
undefined behaviour to use NULL here if we end up with pointer
comparison, but MSVC runtime seems to be happy with it, and most
other systems have typeof() and don't even need pointer comparison
fallback code.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 hashmap.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hashmap.h b/hashmap.h
index ef220de4c6..b011b394fe 100644
--- a/hashmap.h
+++ b/hashmap.h
@@ -449,7 +449,8 @@ static inline struct hashmap_entry *hashmap_iter_first(struct hashmap *map,
  * containing a @member which is a "struct hashmap_entry"
  */
 #define hashmap_for_each_entry(map, iter, var, member) \
-	for (var = hashmap_iter_first_entry_offset(map, iter, \
+	for (var = NULL, /* for systems without typeof */ \
+	     var = hashmap_iter_first_entry_offset(map, iter, \
 						OFFSETOF_VAR(var, member)); \
 		var; \
 		var = hashmap_iter_next_entry_offset(iter, \
-- 
gitgitgadget

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [PATCH v4 08/10] cmake (Windows): initialize vcpkg/build dependencies automatically
  2020-09-30 15:26       ` [PATCH v4 08/10] cmake (Windows): initialize vcpkg/build dependencies automatically Johannes Schindelin via GitGitGadget
@ 2020-09-30 19:17         ` Johannes Schindelin
  2020-09-30 23:08           ` Junio C Hamano
  0 siblings, 1 reply; 70+ messages in thread
From: Johannes Schindelin @ 2020-09-30 19:17 UTC (permalink / raw)
  To: Johannes Schindelin via GitGitGadget
  Cc: git, Sibi Siddharthan, Đoàn Trần Công Danh,
	SZEDER Gábor, Eric Sunshine, Øystein Walle

Hi,


On Wed, 30 Sep 2020, Johannes Schindelin via GitGitGadget wrote:

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> The idea of having CMake support in Git's source tree is to enable
> contributors on Windows to start contributing with little effort. To
> that end, we just added some sensible defaults that will let users open
> the worktree in Visual Studio and start building.
>
> This expects the dependencies (such as zlib) to be available already,
> though. If they are not available, we expect the user to run
> `compat/vcbuild/vcpkg_install.bat`.
>
> Rather than requiring this step to be manual, detect the situation and
> run it as part of the CMake configuration step.
>
> Note that this obviously only applies to the scenario when we want to
> compile in Visual Studio (i.e. with MS Visual C), not with GCC.
> Therefore, we guard this new code block behind the `MSVC` conditional.
>
> This concludes our journey to make it as effortless as possible to start
> developing Git in Visual Studio: all the developer needs to do is to
> clone Git's repository, open the worktree via `File>Open>Folder...` and
> wait for CMake to finish configuring.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> squash! cmake (Windows): initialize vcpkg/build dependencies automatically
>
> MSVC

Aaargh! This was of course meant to be deleted after rewording the commit
message :-(

Sorry about that,
Dscho

> ---
>  contrib/buildsystems/CMakeLists.txt | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
> index 78b90abe5e..ebadae2271 100644
> --- a/contrib/buildsystems/CMakeLists.txt
> +++ b/contrib/buildsystems/CMakeLists.txt
> @@ -42,6 +42,10 @@ cmake_minimum_required(VERSION 3.14)
>  set(CMAKE_SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/../..)
>  if(WIN32)
>  	set(VCPKG_DIR "${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg")
> +	if(MSVC AND NOT EXISTS ${VCPKG_DIR})
> +		message("Initializing vcpkg and building the Git's dependencies (this will take a while...)")
> +		execute_process(COMMAND ${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg_install.bat)
> +	endif()
>  	list(APPEND CMAKE_PREFIX_PATH "${VCPKG_DIR}/installed/x64-windows")
>
>  	# In the vcpkg edition, we need this to be able to link to libcurl
> --
> gitgitgadget
>
>
>

^ permalink raw reply	[flat|nested] 70+ messages in thread

* Re: [PATCH v4 08/10] cmake (Windows): initialize vcpkg/build dependencies automatically
  2020-09-30 19:17         ` Johannes Schindelin
@ 2020-09-30 23:08           ` Junio C Hamano
  0 siblings, 0 replies; 70+ messages in thread
From: Junio C Hamano @ 2020-09-30 23:08 UTC (permalink / raw)
  To: Johannes Schindelin
  Cc: Johannes Schindelin via GitGitGadget, git, Sibi Siddharthan,
	Đoàn Trần Công Danh, SZEDER Gábor,
	Eric Sunshine, Øystein Walle

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

>> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>>
>> squash! cmake (Windows): initialize vcpkg/build dependencies automatically
>>
>> MSVC
>
> Aaargh! This was of course meant to be deleted after rewording the commit
> message :-(

OK.  I noticed it and what got pushed out has them removed.

Hopefully we can merge this round down to 'next' after waiting for a
day or two to see if anything new gets noticed.

Thanks.

^ permalink raw reply	[flat|nested] 70+ messages in thread

end of thread, other threads:[~2020-09-30 23:09 UTC | newest]

Thread overview: 70+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-25 14:28 [PATCH 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
2020-09-25 14:28 ` [PATCH 01/10] cmake: ignore files generated by CMake as run in " Johannes Schindelin via GitGitGadget
2020-09-25 14:28 ` [PATCH 02/10] cmake: do find Git for Windows' shell interpreter Johannes Schindelin via GitGitGadget
2020-09-25 16:25   ` Sibi Siddharthan
2020-09-26 20:32     ` Johannes Schindelin
2020-09-27  2:25       ` Đoàn Trần Công Danh
2020-09-28 13:56         ` Johannes Schindelin
2020-09-29 14:04           ` Đoàn Trần Công Danh
2020-09-29 18:42             ` Johannes Schindelin
2020-09-25 14:28 ` [PATCH 03/10] cmake: ensure that the `vcpkg` packages are found on Windows Johannes Schindelin via GitGitGadget
2020-09-25 14:28 ` [PATCH 04/10] cmake: fall back to using `vcpkg`'s `msgfmt.exe` " Johannes Schindelin via GitGitGadget
2020-09-25 14:28 ` [PATCH 05/10] cmake: quote the path accurately when editing `test-lib.sh` Johannes Schindelin via GitGitGadget
2020-09-25 14:28 ` [PATCH 06/10] cmake (Windows): let the `.dll` files are found when running the tests Johannes Schindelin via GitGitGadget
2020-09-25 19:48   ` Eric Sunshine
2020-09-26 21:00     ` Johannes Schindelin
2020-09-25 14:28 ` [PATCH 07/10] cmake (Windows): complain when encountering an unknown compiler Johannes Schindelin via GitGitGadget
2020-09-25 17:29   ` Sibi Siddharthan
2020-09-26 20:33     ` Johannes Schindelin
2020-09-25 14:28 ` [PATCH 08/10] cmake (Windows): initialize vcpkg/build dependencies automatically Johannes Schindelin via GitGitGadget
2020-09-30  5:05   ` Sibi Siddharthan
2020-09-30 15:25     ` Johannes Schindelin
2020-09-25 14:28 ` [PATCH 09/10] cmake (Windows): recommend using Visual Studio's built-in CMake support Johannes Schindelin via GitGitGadget
2020-09-25 18:22   ` Junio C Hamano
2020-09-26 20:45     ` Johannes Schindelin
2020-09-25 14:28 ` [PATCH 10/10] hashmap_for_each_entry(): work around MSVC's run-time check failure #3 Johannes Schindelin via GitGitGadget
2020-09-25 18:38   ` Junio C Hamano
2020-09-26 16:54     ` Junio C Hamano
2020-09-26 20:57       ` Johannes Schindelin
2020-09-26 21:32 ` [PATCH v2 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
2020-09-26 21:32   ` [PATCH v2 01/10] cmake: ignore files generated by CMake as run in " Johannes Schindelin via GitGitGadget
2020-09-26 21:32   ` [PATCH v2 02/10] cmake: do find Git for Windows' shell interpreter Johannes Schindelin via GitGitGadget
2020-09-28 11:17     ` Øystein Walle
2020-09-28 19:39       ` Johannes Schindelin
2020-09-26 21:32   ` [PATCH v2 03/10] cmake: ensure that the `vcpkg` packages are found on Windows Johannes Schindelin via GitGitGadget
2020-09-26 21:32   ` [PATCH v2 04/10] cmake: fall back to using `vcpkg`'s `msgfmt.exe` " Johannes Schindelin via GitGitGadget
2020-09-26 21:32   ` [PATCH v2 05/10] cmake: quote the path accurately when editing `test-lib.sh` Johannes Schindelin via GitGitGadget
2020-09-26 21:32   ` [PATCH v2 06/10] cmake (Windows): let the `.dll` files be found when running the tests Johannes Schindelin via GitGitGadget
2020-09-26 21:32   ` [PATCH v2 07/10] cmake (Windows): complain when encountering an unknown compiler Johannes Schindelin via GitGitGadget
2020-09-26 21:32   ` [PATCH v2 08/10] cmake (Windows): initialize vcpkg/build dependencies automatically Johannes Schindelin via GitGitGadget
2020-09-26 21:32   ` [PATCH v2 09/10] cmake (Windows): recommend using Visual Studio's built-in CMake support Johannes Schindelin via GitGitGadget
2020-09-26 21:32   ` [PATCH v2 10/10] hashmap_for_each_entry(): workaround MSVC's runtime check failure #3 Junio C Hamano via GitGitGadget
2020-09-28 21:09   ` [PATCH v3 00/11] CMake and Visual Studio Johannes Schindelin via GitGitGadget
2020-09-28 21:09     ` [PATCH v3 01/11] cmake: ignore files generated by CMake as run in " Johannes Schindelin via GitGitGadget
2020-09-28 21:09     ` [PATCH v3 02/11] cmake: do find Git for Windows' shell interpreter Johannes Schindelin via GitGitGadget
2020-09-28 21:09     ` [PATCH v3 03/11] cmake: ensure that the `vcpkg` packages are found on Windows Johannes Schindelin via GitGitGadget
2020-09-28 21:09     ` [PATCH v3 04/11] cmake: fall back to using `vcpkg`'s `msgfmt.exe` " Johannes Schindelin via GitGitGadget
2020-09-28 21:09     ` [PATCH v3 05/11] cmake: quote the path accurately when editing `test-lib.sh` Johannes Schindelin via GitGitGadget
2020-09-28 21:09     ` [PATCH v3 06/11] cmake (Windows): let the `.dll` files be found when running the tests Johannes Schindelin via GitGitGadget
2020-09-28 21:09     ` [PATCH v3 07/11] cmake (Windows): complain when encountering an unknown compiler Johannes Schindelin via GitGitGadget
2020-09-28 21:09     ` [PATCH v3 08/11] cmake (Windows): initialize vcpkg/build dependencies automatically Johannes Schindelin via GitGitGadget
2020-09-29  6:51       ` Sibi Siddharthan
2020-09-29 12:07         ` Johannes Schindelin
2020-09-28 21:09     ` [PATCH v3 09/11] cmake (Windows): recommend using Visual Studio's built-in CMake support Johannes Schindelin via GitGitGadget
2020-09-28 21:09     ` [PATCH v3 10/11] hashmap_for_each_entry(): workaround MSVC's runtime check failure #3 Junio C Hamano via GitGitGadget
2020-09-28 21:09     ` [PATCH v3 11/11] cmake: fix typo in message when `msgfmt` was not found Johannes Schindelin via GitGitGadget
2020-09-28 22:11       ` Junio C Hamano
2020-09-29 12:07         ` Johannes Schindelin
2020-09-30 15:26     ` [PATCH v4 00/10] CMake and Visual Studio Johannes Schindelin via GitGitGadget
2020-09-30 15:26       ` [PATCH v4 01/10] cmake: ignore files generated by CMake as run in " Johannes Schindelin via GitGitGadget
2020-09-30 15:26       ` [PATCH v4 02/10] cmake: do find Git for Windows' shell interpreter Johannes Schindelin via GitGitGadget
2020-09-30 15:26       ` [PATCH v4 03/10] cmake: ensure that the `vcpkg` packages are found on Windows Johannes Schindelin via GitGitGadget
2020-09-30 15:26       ` [PATCH v4 04/10] cmake: fall back to using `vcpkg`'s `msgfmt.exe` " Johannes Schindelin via GitGitGadget
2020-09-30 15:26       ` [PATCH v4 05/10] cmake: quote the path accurately when editing `test-lib.sh` Johannes Schindelin via GitGitGadget
2020-09-30 15:26       ` [PATCH v4 06/10] cmake (Windows): let the `.dll` files be found when running the tests Johannes Schindelin via GitGitGadget
2020-09-30 15:26       ` [PATCH v4 07/10] cmake (Windows): complain when encountering an unknown compiler Johannes Schindelin via GitGitGadget
2020-09-30 15:26       ` [PATCH v4 08/10] cmake (Windows): initialize vcpkg/build dependencies automatically Johannes Schindelin via GitGitGadget
2020-09-30 19:17         ` Johannes Schindelin
2020-09-30 23:08           ` Junio C Hamano
2020-09-30 15:26       ` [PATCH v4 09/10] cmake (Windows): recommend using Visual Studio's built-in CMake support Johannes Schindelin via GitGitGadget
2020-09-30 15:26       ` [PATCH v4 10/10] hashmap_for_each_entry(): workaround MSVC's runtime check failure #3 Junio C Hamano via GitGitGadget

Code repositories for project(s) associated with this 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).