From: Johannes Schindelin via GitGitGadget <hidden> Date: 2021-03-27 23:07:05
In Git for Windows, we would like to make use of the fact that our
CMake-based build can also install the files into their final location. This
patch series helps with that.
Dennis Ameling (2):
cmake(install): fix double .exe suffixes
cmake(install): include vcpkg dlls
Johannes Schindelin (2):
cmake: support SKIP_DASHED_BUILT_INS
cmake: add a preparatory work-around to accommodate `vcpkg`
.github/workflows/main.yml | 5 +++++
contrib/buildsystems/CMakeLists.txt | 26 +++++++++++++++++++-------
2 files changed, 24 insertions(+), 7 deletions(-)
base-commit: 773e25afc41b1b6533fa9ae2cd825d0b4a697fad
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-887%2Fdscho%2Fskip-dashed-built-ins-in-cmake-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-887/dscho/skip-dashed-built-ins-in-cmake-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/887
--
gitgitgadget
From: Johannes Schindelin via GitGitGadget <hidden> Date: 2021-03-27 23:07:05
From: Johannes Schindelin <redacted>
Just like the Makefile-based build learned to skip hard-linking the
dashed built-ins in 179227d6e21 (Optionally skip linking/copying the
built-ins, 2020-09-21), this patch teaches the CMake-based build the
same trick.
Note: In contrast to the Makefile-based process, the built-ins would
only be linked during installation, not already when Git is built.
Therefore, the CMake-based build that we use in our CI builds _already_
does not link those built-ins (because the files are not installed
anywhere, they are used to run the test suite in-place).
Signed-off-by: Johannes Schindelin <redacted>
---
contrib/buildsystems/CMakeLists.txt | 4 ++++
1 file changed, 4 insertions(+)
@@ -685,13 +685,17 @@ endif()parse_makefile_for_executables(git_builtin_extra"BUILT_INS")+option(SKIP_DASHED_BUILT_INS"Skip hardlinking the dashed versions of the built-ins")+#Creating hardlinks+if(NOTSKIP_DASHED_BUILT_INS)foreach(s${git_SOURCES}${git_builtin_extra})string(REPLACE"${CMAKE_SOURCE_DIR}/builtin/"""s${s})string(REPLACE".c"""s${s})file(APPEND${CMAKE_BINARY_DIR}/CreateLinks.cmake"file(CREATE_LINK git${EXE_EXTENSION} git-${s}${EXE_EXTENSION})\n")list(APPENDgit_links${CMAKE_BINARY_DIR}/git-${s}${EXE_EXTENSION})endforeach()+endif()if(CURL_FOUND)set(remote_exes
From: Dennis Ameling via GitGitGadget <hidden> Date: 2021-03-27 23:07:05
From: Dennis Ameling <redacted>
By mistake, the `.exe` extension is appended _twice_ when installing the
dashed executables into `libexec/git-core/` on Windows (the extension is
already appended when adding items to the `git_links` list in the
`#Creating hardlinks` section).
Signed-off-by: Dennis Ameling <redacted>
Signed-off-by: Johannes Schindelin <redacted>
---
contrib/buildsystems/CMakeLists.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Johannes Schindelin via GitGitGadget <hidden> Date: 2021-03-27 23:07:48
From: Johannes Schindelin <redacted>
We are about to add support for installing the `.dll` files of Git's
dependencies (such as libcurl) in the CMake configuration. The `vcpkg`
ecosystem from which we get said dependencies makes that relatively
easy: simply turn on `X_VCPKG_APPLOCAL_DEPS_INSTALL`.
However, current `vcpkg` introduces a limitation if one does that:
While it is totally cool with CMake to specify multiple targets within
one invocation of `install(TARGETS ...) (at least according to
https://cmake.org/cmake/help/latest/command/install.html#command:install),
`vcpkg`'s parser insists on a single target per `install(TARGETS ...)`
invocation.
Well, that's easily accomplished: Let's feed the targets individually to
the `install(TARGETS ...)` function in a `foreach()` look.
This also has the advantage that we do not have to manually cull off the
two entries from the `${PROGRAMS_BUILT}` array before scheduling the
remainder to be installed into `libexec/git-core`. Instead, we iterate
through the array and decide for each entry where it wants to go.
Signed-off-by: Johannes Schindelin <redacted>
---
contrib/buildsystems/CMakeLists.txt | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
From: Dennis Ameling via GitGitGadget <hidden> Date: 2021-03-27 23:07:48
From: Dennis Ameling <redacted>
Our CMake configuration generates not only build definitions, but also
install definitions: After building Git using `msbuild git.sln`, the
built artifacts can be installed via `msbuild INSTALL.vcxproj`.
To specify _where_ the files should be installed, the
`-DCMAKE_INSTALL_PREFIX=<path>` option can be used when running CMake.
However, this process would really only install the files that were just
built. On Windows, we need more than that: We also need the `.dll` files
of the dependencies (such as libcurl). The `vcpkg` ecosystem, which we
use to obtain those dependencies, can be asked to install said `.dll`
files really easily, so let's do that.
This requires more than just the built `vcpkg` artifacts in the CI build
definition; We now clone the `vcpkg` repository so that the relevant
CMake scripts are available, in particular the ones related to defining
the toolchain.
Signed-off-by: Dennis Ameling <redacted>
Signed-off-by: Johannes Schindelin <redacted>
---
.github/workflows/main.yml | 5 +++++
contrib/buildsystems/CMakeLists.txt | 4 ++++
2 files changed, 9 insertions(+)
@@ -58,6 +58,10 @@ if(WIN32)# In the vcpkg edition, we need this to be able to link to libcurlset(CURL_NO_CURL_CMAKEON)++# Copy the necessary vcpkg DLLs (like iconv) to the install dir+set(X_VCPKG_APPLOCAL_DEPS_INSTALLON)+set(CMAKE_TOOLCHAIN_FILE${VCPKG_DIR}/scripts/buildsystems/vcpkg.cmakeCACHESTRING"Vcpkg toolchain file")endif()find_program(SH_EXEshPATHS"C:/Program Files/Git/bin")
From: Đoàn Trần Công Danh <hidden> Date: 2021-03-28 03:26:06
On 2021-03-27 23:06:24+0000, Johannes Schindelin via GitGitGadget [off-list ref] wrote:
quoted hunk
From: Johannes Schindelin <redacted>
We are about to add support for installing the `.dll` files of Git's
dependencies (such as libcurl) in the CMake configuration. The `vcpkg`
ecosystem from which we get said dependencies makes that relatively
easy: simply turn on `X_VCPKG_APPLOCAL_DEPS_INSTALL`.
However, current `vcpkg` introduces a limitation if one does that:
While it is totally cool with CMake to specify multiple targets within
one invocation of `install(TARGETS ...) (at least according to
https://cmake.org/cmake/help/latest/command/install.html#command:install),
`vcpkg`'s parser insists on a single target per `install(TARGETS ...)`
invocation.
Well, that's easily accomplished: Let's feed the targets individually to
the `install(TARGETS ...)` function in a `foreach()` look.
This also has the advantage that we do not have to manually cull off the
two entries from the `${PROGRAMS_BUILT}` array before scheduling the
remainder to be installed into `libexec/git-core`. Instead, we iterate
through the array and decide for each entry where it wants to go.
Signed-off-by: Johannes Schindelin <redacted>
---
contrib/buildsystems/CMakeLists.txt | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
Please don't use `${}` around variable inside `if()`, and quote the
string. CMake has a quirk with the `${}` inside if (expanded variable
will be treated as a variable if it is defined, or string otherwise).
Unquoted string will be seen as a variable if it's defined, string
otherwise. IOW, suggested command:
if (program STREQUAL "git" OR program STREQUAL "git-shell")
We also have another problem with quoted arguments could be interpreted
as variable or keyword if CMP0054 policy not enabled, too.
I think it's better to have it enabled, but it's not in the scope of
this patch.
https://cmake.org/cmake/help/latest/policy/CMP0054.html
--
Danh
From: Johannes Schindelin via GitGitGadget <hidden> Date: 2021-03-29 12:42:26
From: Johannes Schindelin <redacted>
Just like the Makefile-based build learned to skip hard-linking the
dashed built-ins in 179227d6e21 (Optionally skip linking/copying the
built-ins, 2020-09-21), this patch teaches the CMake-based build the
same trick.
Note: In contrast to the Makefile-based process, the built-ins would
only be linked during installation, not already when Git is built.
Therefore, the CMake-based build that we use in our CI builds _already_
does not link those built-ins (because the files are not installed
anywhere, they are used to run the test suite in-place).
Signed-off-by: Johannes Schindelin <redacted>
---
contrib/buildsystems/CMakeLists.txt | 4 ++++
1 file changed, 4 insertions(+)
@@ -685,13 +685,17 @@ endif()parse_makefile_for_executables(git_builtin_extra"BUILT_INS")+option(SKIP_DASHED_BUILT_INS"Skip hardlinking the dashed versions of the built-ins")+#Creating hardlinks+if(NOTSKIP_DASHED_BUILT_INS)foreach(s${git_SOURCES}${git_builtin_extra})string(REPLACE"${CMAKE_SOURCE_DIR}/builtin/"""s${s})string(REPLACE".c"""s${s})file(APPEND${CMAKE_BINARY_DIR}/CreateLinks.cmake"file(CREATE_LINK git${EXE_EXTENSION} git-${s}${EXE_EXTENSION})\n")list(APPENDgit_links${CMAKE_BINARY_DIR}/git-${s}${EXE_EXTENSION})endforeach()+endif()if(CURL_FOUND)set(remote_exes
From: Dennis Ameling via GitGitGadget <hidden> Date: 2021-03-29 12:42:26
From: Dennis Ameling <redacted>
By mistake, the `.exe` extension is appended _twice_ when installing the
dashed executables into `libexec/git-core/` on Windows (the extension is
already appended when adding items to the `git_links` list in the
`#Creating hardlinks` section).
Signed-off-by: Dennis Ameling <redacted>
Signed-off-by: Johannes Schindelin <redacted>
---
contrib/buildsystems/CMakeLists.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Johannes Schindelin via GitGitGadget <hidden> Date: 2021-03-29 12:42:27
In Git for Windows, we would like to make use of the fact that our
CMake-based build can also install the files into their final location. This
patch series helps with that.
Changes since v1:
* Use proper string/variable CMake syntax, as pointed out by Danh
Dennis Ameling (2):
cmake(install): fix double .exe suffixes
cmake(install): include vcpkg dlls
Johannes Schindelin (2):
cmake: support SKIP_DASHED_BUILT_INS
cmake: add a preparatory work-around to accommodate `vcpkg`
.github/workflows/main.yml | 5 +++++
contrib/buildsystems/CMakeLists.txt | 26 +++++++++++++++++++-------
2 files changed, 24 insertions(+), 7 deletions(-)
base-commit: 773e25afc41b1b6533fa9ae2cd825d0b4a697fad
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-887%2Fdscho%2Fskip-dashed-built-ins-in-cmake-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-887/dscho/skip-dashed-built-ins-in-cmake-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/887
Range-diff vs v1:
1: ff7e8121d7a4 = 1: ff7e8121d7a4 cmake: support SKIP_DASHED_BUILT_INS
2: 69856f278645 = 2: 69856f278645 cmake(install): fix double .exe suffixes
3: 543fd0f5d7e5 ! 3: 5d953a21e9bd cmake: add a preparatory work-around to accommodate `vcpkg`
@@ contrib/buildsystems/CMakeLists.txt: list(TRANSFORM git_shell_scripts PREPEND "$
#install
-install(TARGETS git git-shell
+foreach(program ${PROGRAMS_BUILT})
-+if(${program} STREQUAL git OR ${program} STREQUAL git-shell)
++if(program STREQUAL "git" OR program STREQUAL "git-shell")
+install(TARGETS ${program}
RUNTIME DESTINATION bin)
+else()
4: 4b183c7def58 = 4: f020cb517dfc cmake(install): include vcpkg dlls
--
gitgitgadget
From: Dennis Ameling via GitGitGadget <hidden> Date: 2021-03-29 12:42:27
From: Dennis Ameling <redacted>
Our CMake configuration generates not only build definitions, but also
install definitions: After building Git using `msbuild git.sln`, the
built artifacts can be installed via `msbuild INSTALL.vcxproj`.
To specify _where_ the files should be installed, the
`-DCMAKE_INSTALL_PREFIX=<path>` option can be used when running CMake.
However, this process would really only install the files that were just
built. On Windows, we need more than that: We also need the `.dll` files
of the dependencies (such as libcurl). The `vcpkg` ecosystem, which we
use to obtain those dependencies, can be asked to install said `.dll`
files really easily, so let's do that.
This requires more than just the built `vcpkg` artifacts in the CI build
definition; We now clone the `vcpkg` repository so that the relevant
CMake scripts are available, in particular the ones related to defining
the toolchain.
Signed-off-by: Dennis Ameling <redacted>
Signed-off-by: Johannes Schindelin <redacted>
---
.github/workflows/main.yml | 5 +++++
contrib/buildsystems/CMakeLists.txt | 4 ++++
2 files changed, 9 insertions(+)
@@ -58,6 +58,10 @@ if(WIN32)# In the vcpkg edition, we need this to be able to link to libcurlset(CURL_NO_CURL_CMAKEON)++# Copy the necessary vcpkg DLLs (like iconv) to the install dir+set(X_VCPKG_APPLOCAL_DEPS_INSTALLON)+set(CMAKE_TOOLCHAIN_FILE${VCPKG_DIR}/scripts/buildsystems/vcpkg.cmakeCACHESTRING"Vcpkg toolchain file")endif()find_program(SH_EXEshPATHS"C:/Program Files/Git/bin")
From: Johannes Schindelin via GitGitGadget <hidden> Date: 2021-03-29 12:42:27
From: Johannes Schindelin <redacted>
We are about to add support for installing the `.dll` files of Git's
dependencies (such as libcurl) in the CMake configuration. The `vcpkg`
ecosystem from which we get said dependencies makes that relatively
easy: simply turn on `X_VCPKG_APPLOCAL_DEPS_INSTALL`.
However, current `vcpkg` introduces a limitation if one does that:
While it is totally cool with CMake to specify multiple targets within
one invocation of `install(TARGETS ...) (at least according to
https://cmake.org/cmake/help/latest/command/install.html#command:install),
`vcpkg`'s parser insists on a single target per `install(TARGETS ...)`
invocation.
Well, that's easily accomplished: Let's feed the targets individually to
the `install(TARGETS ...)` function in a `foreach()` look.
This also has the advantage that we do not have to manually cull off the
two entries from the `${PROGRAMS_BUILT}` array before scheduling the
remainder to be installed into `libexec/git-core`. Instead, we iterate
through the array and decide for each entry where it wants to go.
Signed-off-by: Johannes Schindelin <redacted>
---
contrib/buildsystems/CMakeLists.txt | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
From: Johannes Schindelin <hidden> Date: 2021-03-29 13:36:57
Hi Danh,
On Sun, 28 Mar 2021, Đoàn Trần Công Danh wrote:
On 2021-03-27 23:06:24+0000, Johannes Schindelin via GitGitGadget [off-list ref] wrote:
quoted
From: Johannes Schindelin <redacted>
We are about to add support for installing the `.dll` files of Git's
dependencies (such as libcurl) in the CMake configuration. The `vcpkg`
ecosystem from which we get said dependencies makes that relatively
easy: simply turn on `X_VCPKG_APPLOCAL_DEPS_INSTALL`.
However, current `vcpkg` introduces a limitation if one does that:
While it is totally cool with CMake to specify multiple targets within
one invocation of `install(TARGETS ...) (at least according to
https://cmake.org/cmake/help/latest/command/install.html#command:install),
`vcpkg`'s parser insists on a single target per `install(TARGETS ...)`
invocation.
Well, that's easily accomplished: Let's feed the targets individually to
the `install(TARGETS ...)` function in a `foreach()` look.
This also has the advantage that we do not have to manually cull off the
two entries from the `${PROGRAMS_BUILT}` array before scheduling the
remainder to be installed into `libexec/git-core`. Instead, we iterate
through the array and decide for each entry where it wants to go.
Signed-off-by: Johannes Schindelin <redacted>
---
contrib/buildsystems/CMakeLists.txt | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
Please don't use `${}` around variable inside `if()`, and quote the
string. CMake has a quirk with the `${}` inside if (expanded variable
will be treated as a variable if it is defined, or string otherwise).
Unquoted string will be seen as a variable if it's defined, string
otherwise. IOW, suggested command:
if (program STREQUAL "git" OR program STREQUAL "git-shell")
We also have another problem with quoted arguments could be interpreted
as variable or keyword if CMP0054 policy not enabled, too.
I think it's better to have it enabled, but it's not in the scope of
this patch.
https://cmake.org/cmake/help/latest/policy/CMP0054.html
Thank you for this information! I've sent out v2 based on your suggestion.
Thanks,
Dscho