Introduce CMake support for configuring Git
At the moment, the recommended way to configure Git's builds is to
simply run `make`. If that does not work, the recommended strategy is to
look at the top of the `Makefile` to see whether any "Makefile knob" has
to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`.
Alternatively, Git also has an `autoconf` setup which allows configuring
builds via `./configure [<option>...]`.
Both of these options are fine if the developer works on Unix or Linux.
But on Windows, we have to jump through hoops to configure a build
(read: we force the user to install a full Git for Windows SDK, which
occupies around two gigabytes (!) on disk and downloads about three
quarters of a gigabyte worth of Git objects).
The build infrastructure for Git is written around being able to run
make, which is not supported natively on Windows.
To help Windows developers a CMake build script is introduced here.
With a working support CMake, developers on Windows need only install
CMake, configure their build, load the generated Visual Studio solution
and immediately start modifying the code and build their own version of
Git. Likewise, developers on other platforms can use the convenient GUI
tools provided by CMake to configure their build.
So let's start building CMake support for Git.
This is only the first step, and to make it easier to review, it only
allows for configuring builds on the platform that is easiest to
configure for: Linux.
The CMake script checks whether the headers are present(eg. libgen.h),
whether the functions are present(eg. memmem), whether the funtions work
properly (eg. snprintf) and generate the required compile definitions
for the platform. The script also searches for the required libraries,
if it fails to find the required libraries the respective executables
won't be built.(eg. If libcurl is not found then git-remote-http won't
be built). This will help building Git easier.
With a CMake script an out of source build of git is possible resulting
in a clean source tree.
Note: this patch asks for the minimum version v3.14 of CMake (which is
not all that old as of time of writing) because that is the first
version to offer a platform-independent way to generate hardlinks as
part of the build. This is needed to generate all those hardlinks for
the built-in commands of Git.
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-12 20:29:19 +02:00
|
|
|
#
|
|
|
|
|
# Copyright (c) 2020 Sibi Siddharthan
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
#[[
|
|
|
|
|
|
2020-09-30 17:26:23 +02:00
|
|
|
Instructions how to use this in Visual Studio:
|
Introduce CMake support for configuring Git
At the moment, the recommended way to configure Git's builds is to
simply run `make`. If that does not work, the recommended strategy is to
look at the top of the `Makefile` to see whether any "Makefile knob" has
to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`.
Alternatively, Git also has an `autoconf` setup which allows configuring
builds via `./configure [<option>...]`.
Both of these options are fine if the developer works on Unix or Linux.
But on Windows, we have to jump through hoops to configure a build
(read: we force the user to install a full Git for Windows SDK, which
occupies around two gigabytes (!) on disk and downloads about three
quarters of a gigabyte worth of Git objects).
The build infrastructure for Git is written around being able to run
make, which is not supported natively on Windows.
To help Windows developers a CMake build script is introduced here.
With a working support CMake, developers on Windows need only install
CMake, configure their build, load the generated Visual Studio solution
and immediately start modifying the code and build their own version of
Git. Likewise, developers on other platforms can use the convenient GUI
tools provided by CMake to configure their build.
So let's start building CMake support for Git.
This is only the first step, and to make it easier to review, it only
allows for configuring builds on the platform that is easiest to
configure for: Linux.
The CMake script checks whether the headers are present(eg. libgen.h),
whether the functions are present(eg. memmem), whether the funtions work
properly (eg. snprintf) and generate the required compile definitions
for the platform. The script also searches for the required libraries,
if it fails to find the required libraries the respective executables
won't be built.(eg. If libcurl is not found then git-remote-http won't
be built). This will help building Git easier.
With a CMake script an out of source build of git is possible resulting
in a clean source tree.
Note: this patch asks for the minimum version v3.14 of CMake (which is
not all that old as of time of writing) because that is the first
version to offer a platform-independent way to generate hardlinks as
part of the build. This is needed to generate all those hardlinks for
the built-in commands of Git.
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-12 20:29:19 +02:00
|
|
|
|
2020-09-30 17:26:23 +02:00
|
|
|
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.
|
Introduce CMake support for configuring Git
At the moment, the recommended way to configure Git's builds is to
simply run `make`. If that does not work, the recommended strategy is to
look at the top of the `Makefile` to see whether any "Makefile knob" has
to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`.
Alternatively, Git also has an `autoconf` setup which allows configuring
builds via `./configure [<option>...]`.
Both of these options are fine if the developer works on Unix or Linux.
But on Windows, we have to jump through hoops to configure a build
(read: we force the user to install a full Git for Windows SDK, which
occupies around two gigabytes (!) on disk and downloads about three
quarters of a gigabyte worth of Git objects).
The build infrastructure for Git is written around being able to run
make, which is not supported natively on Windows.
To help Windows developers a CMake build script is introduced here.
With a working support CMake, developers on Windows need only install
CMake, configure their build, load the generated Visual Studio solution
and immediately start modifying the code and build their own version of
Git. Likewise, developers on other platforms can use the convenient GUI
tools provided by CMake to configure their build.
So let's start building CMake support for Git.
This is only the first step, and to make it easier to review, it only
allows for configuring builds on the platform that is easiest to
configure for: Linux.
The CMake script checks whether the headers are present(eg. libgen.h),
whether the functions are present(eg. memmem), whether the funtions work
properly (eg. snprintf) and generate the required compile definitions
for the platform. The script also searches for the required libraries,
if it fails to find the required libraries the respective executables
won't be built.(eg. If libcurl is not found then git-remote-http won't
be built). This will help building Git easier.
With a CMake script an out of source build of git is possible resulting
in a clean source tree.
Note: this patch asks for the minimum version v3.14 of CMake (which is
not all that old as of time of writing) because that is the first
version to offer a platform-independent way to generate hardlinks as
part of the build. This is needed to generate all those hardlinks for
the built-in commands of Git.
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-12 20:29:19 +02:00
|
|
|
|
2020-09-30 17:26:23 +02:00
|
|
|
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).
|
Introduce CMake support for configuring Git
At the moment, the recommended way to configure Git's builds is to
simply run `make`. If that does not work, the recommended strategy is to
look at the top of the `Makefile` to see whether any "Makefile knob" has
to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`.
Alternatively, Git also has an `autoconf` setup which allows configuring
builds via `./configure [<option>...]`.
Both of these options are fine if the developer works on Unix or Linux.
But on Windows, we have to jump through hoops to configure a build
(read: we force the user to install a full Git for Windows SDK, which
occupies around two gigabytes (!) on disk and downloads about three
quarters of a gigabyte worth of Git objects).
The build infrastructure for Git is written around being able to run
make, which is not supported natively on Windows.
To help Windows developers a CMake build script is introduced here.
With a working support CMake, developers on Windows need only install
CMake, configure their build, load the generated Visual Studio solution
and immediately start modifying the code and build their own version of
Git. Likewise, developers on other platforms can use the convenient GUI
tools provided by CMake to configure their build.
So let's start building CMake support for Git.
This is only the first step, and to make it easier to review, it only
allows for configuring builds on the platform that is easiest to
configure for: Linux.
The CMake script checks whether the headers are present(eg. libgen.h),
whether the functions are present(eg. memmem), whether the funtions work
properly (eg. snprintf) and generate the required compile definitions
for the platform. The script also searches for the required libraries,
if it fails to find the required libraries the respective executables
won't be built.(eg. If libcurl is not found then git-remote-http won't
be built). This will help building Git easier.
With a CMake script an out of source build of git is possible resulting
in a clean source tree.
Note: this patch asks for the minimum version v3.14 of CMake (which is
not all that old as of time of writing) because that is the first
version to offer a platform-independent way to generate hardlinks as
part of the build. This is needed to generate all those hardlinks for
the built-in commands of Git.
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-12 20:29:19 +02:00
|
|
|
|
|
|
|
|
Possible build configurations(-DCMAKE_BUILD_TYPE) with corresponding
|
|
|
|
|
compiler flags
|
|
|
|
|
Debug : -g
|
|
|
|
|
Release: -O3
|
|
|
|
|
RelWithDebInfo : -O2 -g
|
|
|
|
|
MinSizeRel : -Os
|
|
|
|
|
empty(default) :
|
|
|
|
|
|
|
|
|
|
NOTE: -DCMAKE_BUILD_TYPE is optional. For multi-config generators like Visual Studio
|
|
|
|
|
this option is ignored
|
|
|
|
|
|
|
|
|
|
This process generates a Makefile(Linux/*BSD/MacOS) , Visual Studio solution(Windows) by default.
|
|
|
|
|
Run `make` to build Git on Linux/*BSD/MacOS.
|
|
|
|
|
Open git.sln on Windows and build Git.
|
|
|
|
|
|
|
|
|
|
NOTE: By default CMake uses Makefile as the build tool on Linux and Visual Studio in Windows,
|
|
|
|
|
to use another tool say `ninja` add this to the command line when configuring.
|
|
|
|
|
`-G Ninja`
|
|
|
|
|
|
2021-06-06 14:02:52 +02:00
|
|
|
NOTE: By default CMake will install vcpkg locally to your source tree on configuration,
|
|
|
|
|
to avoid this, add `-DNO_VCPKG=TRUE` to the command line when configuring.
|
|
|
|
|
|
Introduce CMake support for configuring Git
At the moment, the recommended way to configure Git's builds is to
simply run `make`. If that does not work, the recommended strategy is to
look at the top of the `Makefile` to see whether any "Makefile knob" has
to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`.
Alternatively, Git also has an `autoconf` setup which allows configuring
builds via `./configure [<option>...]`.
Both of these options are fine if the developer works on Unix or Linux.
But on Windows, we have to jump through hoops to configure a build
(read: we force the user to install a full Git for Windows SDK, which
occupies around two gigabytes (!) on disk and downloads about three
quarters of a gigabyte worth of Git objects).
The build infrastructure for Git is written around being able to run
make, which is not supported natively on Windows.
To help Windows developers a CMake build script is introduced here.
With a working support CMake, developers on Windows need only install
CMake, configure their build, load the generated Visual Studio solution
and immediately start modifying the code and build their own version of
Git. Likewise, developers on other platforms can use the convenient GUI
tools provided by CMake to configure their build.
So let's start building CMake support for Git.
This is only the first step, and to make it easier to review, it only
allows for configuring builds on the platform that is easiest to
configure for: Linux.
The CMake script checks whether the headers are present(eg. libgen.h),
whether the functions are present(eg. memmem), whether the funtions work
properly (eg. snprintf) and generate the required compile definitions
for the platform. The script also searches for the required libraries,
if it fails to find the required libraries the respective executables
won't be built.(eg. If libcurl is not found then git-remote-http won't
be built). This will help building Git easier.
With a CMake script an out of source build of git is possible resulting
in a clean source tree.
Note: this patch asks for the minimum version v3.14 of CMake (which is
not all that old as of time of writing) because that is the first
version to offer a platform-independent way to generate hardlinks as
part of the build. This is needed to generate all those hardlinks for
the built-in commands of Git.
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-12 20:29:19 +02:00
|
|
|
]]
|
|
|
|
|
cmake_minimum_required(VERSION 3.14)
|
|
|
|
|
|
|
|
|
|
#set the source directory to root of git
|
|
|
|
|
set(CMAKE_SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/../..)
|
2021-06-06 14:02:52 +02:00
|
|
|
|
|
|
|
|
option(USE_VCPKG "Whether or not to use vcpkg for obtaining dependencies. Only applicable to Windows platforms" ON)
|
|
|
|
|
if(NOT WIN32)
|
|
|
|
|
set(USE_VCPKG OFF CACHE BOOL FORCE)
|
|
|
|
|
endif()
|
|
|
|
|
|
2021-06-06 14:02:53 +02:00
|
|
|
if(NOT DEFINED CMAKE_EXPORT_COMPILE_COMMANDS)
|
|
|
|
|
set(CMAKE_EXPORT_COMPILE_COMMANDS TRUE)
|
|
|
|
|
endif()
|
|
|
|
|
|
2021-06-06 14:02:52 +02:00
|
|
|
if(USE_VCPKG)
|
2020-09-28 23:09:08 +02:00
|
|
|
set(VCPKG_DIR "${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg")
|
2021-06-06 14:02:52 +02:00
|
|
|
if(NOT EXISTS ${VCPKG_DIR})
|
2020-09-30 17:26:22 +02:00
|
|
|
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()
|
2020-09-28 23:09:08 +02:00
|
|
|
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)
|
2021-03-29 14:41:45 +02:00
|
|
|
|
|
|
|
|
# Copy the necessary vcpkg DLLs (like iconv) to the install dir
|
|
|
|
|
set(X_VCPKG_APPLOCAL_DEPS_INSTALL ON)
|
|
|
|
|
set(CMAKE_TOOLCHAIN_FILE ${VCPKG_DIR}/scripts/buildsystems/vcpkg.cmake CACHE STRING "Vcpkg toolchain file")
|
2020-09-28 23:09:08 +02:00
|
|
|
endif()
|
Introduce CMake support for configuring Git
At the moment, the recommended way to configure Git's builds is to
simply run `make`. If that does not work, the recommended strategy is to
look at the top of the `Makefile` to see whether any "Makefile knob" has
to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`.
Alternatively, Git also has an `autoconf` setup which allows configuring
builds via `./configure [<option>...]`.
Both of these options are fine if the developer works on Unix or Linux.
But on Windows, we have to jump through hoops to configure a build
(read: we force the user to install a full Git for Windows SDK, which
occupies around two gigabytes (!) on disk and downloads about three
quarters of a gigabyte worth of Git objects).
The build infrastructure for Git is written around being able to run
make, which is not supported natively on Windows.
To help Windows developers a CMake build script is introduced here.
With a working support CMake, developers on Windows need only install
CMake, configure their build, load the generated Visual Studio solution
and immediately start modifying the code and build their own version of
Git. Likewise, developers on other platforms can use the convenient GUI
tools provided by CMake to configure their build.
So let's start building CMake support for Git.
This is only the first step, and to make it easier to review, it only
allows for configuring builds on the platform that is easiest to
configure for: Linux.
The CMake script checks whether the headers are present(eg. libgen.h),
whether the functions are present(eg. memmem), whether the funtions work
properly (eg. snprintf) and generate the required compile definitions
for the platform. The script also searches for the required libraries,
if it fails to find the required libraries the respective executables
won't be built.(eg. If libcurl is not found then git-remote-http won't
be built). This will help building Git easier.
With a CMake script an out of source build of git is possible resulting
in a clean source tree.
Note: this patch asks for the minimum version v3.14 of CMake (which is
not all that old as of time of writing) because that is the first
version to offer a platform-independent way to generate hardlinks as
part of the build. This is needed to generate all those hardlinks for
the built-in commands of Git.
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-12 20:29:19 +02:00
|
|
|
|
2020-09-28 23:09:07 +02:00
|
|
|
find_program(SH_EXE sh PATHS "C:/Program Files/Git/bin")
|
2020-06-26 18:11:36 +02:00
|
|
|
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/")
|
|
|
|
|
endif()
|
Introduce CMake support for configuring Git
At the moment, the recommended way to configure Git's builds is to
simply run `make`. If that does not work, the recommended strategy is to
look at the top of the `Makefile` to see whether any "Makefile knob" has
to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`.
Alternatively, Git also has an `autoconf` setup which allows configuring
builds via `./configure [<option>...]`.
Both of these options are fine if the developer works on Unix or Linux.
But on Windows, we have to jump through hoops to configure a build
(read: we force the user to install a full Git for Windows SDK, which
occupies around two gigabytes (!) on disk and downloads about three
quarters of a gigabyte worth of Git objects).
The build infrastructure for Git is written around being able to run
make, which is not supported natively on Windows.
To help Windows developers a CMake build script is introduced here.
With a working support CMake, developers on Windows need only install
CMake, configure their build, load the generated Visual Studio solution
and immediately start modifying the code and build their own version of
Git. Likewise, developers on other platforms can use the convenient GUI
tools provided by CMake to configure their build.
So let's start building CMake support for Git.
This is only the first step, and to make it easier to review, it only
allows for configuring builds on the platform that is easiest to
configure for: Linux.
The CMake script checks whether the headers are present(eg. libgen.h),
whether the functions are present(eg. memmem), whether the funtions work
properly (eg. snprintf) and generate the required compile definitions
for the platform. The script also searches for the required libraries,
if it fails to find the required libraries the respective executables
won't be built.(eg. If libcurl is not found then git-remote-http won't
be built). This will help building Git easier.
With a CMake script an out of source build of git is possible resulting
in a clean source tree.
Note: this patch asks for the minimum version v3.14 of CMake (which is
not all that old as of time of writing) because that is the first
version to offer a platform-independent way to generate hardlinks as
part of the build. This is needed to generate all those hardlinks for
the built-in commands of Git.
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-12 20:29:19 +02:00
|
|
|
|
|
|
|
|
#Create GIT-VERSION-FILE using GIT-VERSION-GEN
|
|
|
|
|
if(NOT EXISTS ${CMAKE_SOURCE_DIR}/GIT-VERSION-FILE)
|
|
|
|
|
message("Generating GIT-VERSION-FILE")
|
|
|
|
|
execute_process(COMMAND ${SH_EXE} ${CMAKE_SOURCE_DIR}/GIT-VERSION-GEN
|
|
|
|
|
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR})
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
#Parse GIT-VERSION-FILE to get the version
|
|
|
|
|
file(STRINGS ${CMAKE_SOURCE_DIR}/GIT-VERSION-FILE git_version REGEX "GIT_VERSION = (.*)")
|
|
|
|
|
string(REPLACE "GIT_VERSION = " "" git_version ${git_version})
|
|
|
|
|
string(FIND ${git_version} "GIT" location)
|
|
|
|
|
if(location EQUAL -1)
|
|
|
|
|
string(REGEX MATCH "[0-9]*\\.[0-9]*\\.[0-9]*" git_version ${git_version})
|
|
|
|
|
else()
|
|
|
|
|
string(REGEX MATCH "[0-9]*\\.[0-9]*" git_version ${git_version})
|
|
|
|
|
string(APPEND git_version ".0") #for building from a snapshot
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
project(git
|
|
|
|
|
VERSION ${git_version}
|
|
|
|
|
LANGUAGES C)
|
|
|
|
|
|
2020-06-26 18:11:36 +02:00
|
|
|
|
2020-06-26 18:11:33 +02:00
|
|
|
#TODO gitk git-gui gitweb
|
2020-06-26 18:11:36 +02:00
|
|
|
#TODO Enable NLS on windows natively
|
2020-06-26 18:11:33 +02:00
|
|
|
#TODO Add pcre support
|
Introduce CMake support for configuring Git
At the moment, the recommended way to configure Git's builds is to
simply run `make`. If that does not work, the recommended strategy is to
look at the top of the `Makefile` to see whether any "Makefile knob" has
to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`.
Alternatively, Git also has an `autoconf` setup which allows configuring
builds via `./configure [<option>...]`.
Both of these options are fine if the developer works on Unix or Linux.
But on Windows, we have to jump through hoops to configure a build
(read: we force the user to install a full Git for Windows SDK, which
occupies around two gigabytes (!) on disk and downloads about three
quarters of a gigabyte worth of Git objects).
The build infrastructure for Git is written around being able to run
make, which is not supported natively on Windows.
To help Windows developers a CMake build script is introduced here.
With a working support CMake, developers on Windows need only install
CMake, configure their build, load the generated Visual Studio solution
and immediately start modifying the code and build their own version of
Git. Likewise, developers on other platforms can use the convenient GUI
tools provided by CMake to configure their build.
So let's start building CMake support for Git.
This is only the first step, and to make it easier to review, it only
allows for configuring builds on the platform that is easiest to
configure for: Linux.
The CMake script checks whether the headers are present(eg. libgen.h),
whether the functions are present(eg. memmem), whether the funtions work
properly (eg. snprintf) and generate the required compile definitions
for the platform. The script also searches for the required libraries,
if it fails to find the required libraries the respective executables
won't be built.(eg. If libcurl is not found then git-remote-http won't
be built). This will help building Git easier.
With a CMake script an out of source build of git is possible resulting
in a clean source tree.
Note: this patch asks for the minimum version v3.14 of CMake (which is
not all that old as of time of writing) because that is the first
version to offer a platform-independent way to generate hardlinks as
part of the build. This is needed to generate all those hardlinks for
the built-in commands of Git.
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-12 20:29:19 +02:00
|
|
|
|
2020-06-26 18:11:32 +02:00
|
|
|
#macros for parsing the Makefile for sources and scripts
|
Introduce CMake support for configuring Git
At the moment, the recommended way to configure Git's builds is to
simply run `make`. If that does not work, the recommended strategy is to
look at the top of the `Makefile` to see whether any "Makefile knob" has
to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`.
Alternatively, Git also has an `autoconf` setup which allows configuring
builds via `./configure [<option>...]`.
Both of these options are fine if the developer works on Unix or Linux.
But on Windows, we have to jump through hoops to configure a build
(read: we force the user to install a full Git for Windows SDK, which
occupies around two gigabytes (!) on disk and downloads about three
quarters of a gigabyte worth of Git objects).
The build infrastructure for Git is written around being able to run
make, which is not supported natively on Windows.
To help Windows developers a CMake build script is introduced here.
With a working support CMake, developers on Windows need only install
CMake, configure their build, load the generated Visual Studio solution
and immediately start modifying the code and build their own version of
Git. Likewise, developers on other platforms can use the convenient GUI
tools provided by CMake to configure their build.
So let's start building CMake support for Git.
This is only the first step, and to make it easier to review, it only
allows for configuring builds on the platform that is easiest to
configure for: Linux.
The CMake script checks whether the headers are present(eg. libgen.h),
whether the functions are present(eg. memmem), whether the funtions work
properly (eg. snprintf) and generate the required compile definitions
for the platform. The script also searches for the required libraries,
if it fails to find the required libraries the respective executables
won't be built.(eg. If libcurl is not found then git-remote-http won't
be built). This will help building Git easier.
With a CMake script an out of source build of git is possible resulting
in a clean source tree.
Note: this patch asks for the minimum version v3.14 of CMake (which is
not all that old as of time of writing) because that is the first
version to offer a platform-independent way to generate hardlinks as
part of the build. This is needed to generate all those hardlinks for
the built-in commands of Git.
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-12 20:29:19 +02:00
|
|
|
macro(parse_makefile_for_sources list_var regex)
|
|
|
|
|
file(STRINGS ${CMAKE_SOURCE_DIR}/Makefile ${list_var} REGEX "^${regex} \\+=(.*)")
|
|
|
|
|
string(REPLACE "${regex} +=" "" ${list_var} ${${list_var}})
|
|
|
|
|
string(REPLACE "$(COMPAT_OBJS)" "" ${list_var} ${${list_var}}) #remove "$(COMPAT_OBJS)" This is only for libgit.
|
|
|
|
|
string(STRIP ${${list_var}} ${list_var}) #remove trailing/leading whitespaces
|
|
|
|
|
string(REPLACE ".o" ".c;" ${list_var} ${${list_var}}) #change .o to .c, ; is for converting the string into a list
|
|
|
|
|
list(TRANSFORM ${list_var} STRIP) #remove trailing/leading whitespaces for each element in list
|
|
|
|
|
list(REMOVE_ITEM ${list_var} "") #remove empty list elements
|
|
|
|
|
endmacro()
|
|
|
|
|
|
2020-06-26 18:11:32 +02:00
|
|
|
macro(parse_makefile_for_scripts list_var regex lang)
|
|
|
|
|
file(STRINGS ${CMAKE_SOURCE_DIR}/Makefile ${list_var} REGEX "^${regex} \\+=(.*)")
|
|
|
|
|
string(REPLACE "${regex} +=" "" ${list_var} ${${list_var}})
|
|
|
|
|
string(STRIP ${${list_var}} ${list_var}) #remove trailing/leading whitespaces
|
|
|
|
|
string(REPLACE " " ";" ${list_var} ${${list_var}}) #convert string to a list
|
|
|
|
|
if(NOT ${lang}) #exclude for SCRIPT_LIB
|
|
|
|
|
list(TRANSFORM ${list_var} REPLACE "${lang}" "") #do the replacement
|
|
|
|
|
endif()
|
|
|
|
|
endmacro()
|
|
|
|
|
|
2020-12-04 20:33:56 +01:00
|
|
|
macro(parse_makefile_for_executables list_var regex)
|
|
|
|
|
file(STRINGS ${CMAKE_SOURCE_DIR}/Makefile ${list_var} REGEX "^${regex} \\+= git-(.*)")
|
|
|
|
|
string(REPLACE "${regex} +=" "" ${list_var} ${${list_var}})
|
|
|
|
|
string(STRIP ${${list_var}} ${list_var}) #remove trailing/leading whitespaces
|
|
|
|
|
string(REPLACE "git-" "" ${list_var} ${${list_var}}) #strip `git-` prefix
|
|
|
|
|
string(REPLACE "\$X" ";" ${list_var} ${${list_var}}) #strip $X, ; is for converting the string into a list
|
|
|
|
|
list(TRANSFORM ${list_var} STRIP) #remove trailing/leading whitespaces for each element in list
|
|
|
|
|
list(REMOVE_ITEM ${list_var} "") #remove empty list elements
|
|
|
|
|
endmacro()
|
|
|
|
|
|
Introduce CMake support for configuring Git
At the moment, the recommended way to configure Git's builds is to
simply run `make`. If that does not work, the recommended strategy is to
look at the top of the `Makefile` to see whether any "Makefile knob" has
to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`.
Alternatively, Git also has an `autoconf` setup which allows configuring
builds via `./configure [<option>...]`.
Both of these options are fine if the developer works on Unix or Linux.
But on Windows, we have to jump through hoops to configure a build
(read: we force the user to install a full Git for Windows SDK, which
occupies around two gigabytes (!) on disk and downloads about three
quarters of a gigabyte worth of Git objects).
The build infrastructure for Git is written around being able to run
make, which is not supported natively on Windows.
To help Windows developers a CMake build script is introduced here.
With a working support CMake, developers on Windows need only install
CMake, configure their build, load the generated Visual Studio solution
and immediately start modifying the code and build their own version of
Git. Likewise, developers on other platforms can use the convenient GUI
tools provided by CMake to configure their build.
So let's start building CMake support for Git.
This is only the first step, and to make it easier to review, it only
allows for configuring builds on the platform that is easiest to
configure for: Linux.
The CMake script checks whether the headers are present(eg. libgen.h),
whether the functions are present(eg. memmem), whether the funtions work
properly (eg. snprintf) and generate the required compile definitions
for the platform. The script also searches for the required libraries,
if it fails to find the required libraries the respective executables
won't be built.(eg. If libcurl is not found then git-remote-http won't
be built). This will help building Git easier.
With a CMake script an out of source build of git is possible resulting
in a clean source tree.
Note: this patch asks for the minimum version v3.14 of CMake (which is
not all that old as of time of writing) because that is the first
version to offer a platform-independent way to generate hardlinks as
part of the build. This is needed to generate all those hardlinks for
the built-in commands of Git.
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-12 20:29:19 +02:00
|
|
|
include(CheckTypeSize)
|
|
|
|
|
include(CheckCSourceRuns)
|
|
|
|
|
include(CheckCSourceCompiles)
|
|
|
|
|
include(CheckIncludeFile)
|
|
|
|
|
include(CheckFunctionExists)
|
|
|
|
|
include(CheckSymbolExists)
|
|
|
|
|
include(CheckStructHasMember)
|
2020-06-26 18:11:34 +02:00
|
|
|
include(CTest)
|
Introduce CMake support for configuring Git
At the moment, the recommended way to configure Git's builds is to
simply run `make`. If that does not work, the recommended strategy is to
look at the top of the `Makefile` to see whether any "Makefile knob" has
to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`.
Alternatively, Git also has an `autoconf` setup which allows configuring
builds via `./configure [<option>...]`.
Both of these options are fine if the developer works on Unix or Linux.
But on Windows, we have to jump through hoops to configure a build
(read: we force the user to install a full Git for Windows SDK, which
occupies around two gigabytes (!) on disk and downloads about three
quarters of a gigabyte worth of Git objects).
The build infrastructure for Git is written around being able to run
make, which is not supported natively on Windows.
To help Windows developers a CMake build script is introduced here.
With a working support CMake, developers on Windows need only install
CMake, configure their build, load the generated Visual Studio solution
and immediately start modifying the code and build their own version of
Git. Likewise, developers on other platforms can use the convenient GUI
tools provided by CMake to configure their build.
So let's start building CMake support for Git.
This is only the first step, and to make it easier to review, it only
allows for configuring builds on the platform that is easiest to
configure for: Linux.
The CMake script checks whether the headers are present(eg. libgen.h),
whether the functions are present(eg. memmem), whether the funtions work
properly (eg. snprintf) and generate the required compile definitions
for the platform. The script also searches for the required libraries,
if it fails to find the required libraries the respective executables
won't be built.(eg. If libcurl is not found then git-remote-http won't
be built). This will help building Git easier.
With a CMake script an out of source build of git is possible resulting
in a clean source tree.
Note: this patch asks for the minimum version v3.14 of CMake (which is
not all that old as of time of writing) because that is the first
version to offer a platform-independent way to generate hardlinks as
part of the build. This is needed to generate all those hardlinks for
the built-in commands of Git.
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-12 20:29:19 +02:00
|
|
|
|
|
|
|
|
find_package(ZLIB REQUIRED)
|
|
|
|
|
find_package(CURL)
|
|
|
|
|
find_package(EXPAT)
|
|
|
|
|
find_package(Iconv)
|
|
|
|
|
|
2020-06-26 18:11:37 +02:00
|
|
|
#Don't use libintl on Windows Visual Studio and Clang builds
|
|
|
|
|
if(NOT (WIN32 AND (CMAKE_C_COMPILER_ID STREQUAL "MSVC" OR CMAKE_C_COMPILER_ID STREQUAL "Clang")))
|
|
|
|
|
find_package(Intl)
|
|
|
|
|
endif()
|
2020-06-26 18:11:36 +02:00
|
|
|
|
Introduce CMake support for configuring Git
At the moment, the recommended way to configure Git's builds is to
simply run `make`. If that does not work, the recommended strategy is to
look at the top of the `Makefile` to see whether any "Makefile knob" has
to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`.
Alternatively, Git also has an `autoconf` setup which allows configuring
builds via `./configure [<option>...]`.
Both of these options are fine if the developer works on Unix or Linux.
But on Windows, we have to jump through hoops to configure a build
(read: we force the user to install a full Git for Windows SDK, which
occupies around two gigabytes (!) on disk and downloads about three
quarters of a gigabyte worth of Git objects).
The build infrastructure for Git is written around being able to run
make, which is not supported natively on Windows.
To help Windows developers a CMake build script is introduced here.
With a working support CMake, developers on Windows need only install
CMake, configure their build, load the generated Visual Studio solution
and immediately start modifying the code and build their own version of
Git. Likewise, developers on other platforms can use the convenient GUI
tools provided by CMake to configure their build.
So let's start building CMake support for Git.
This is only the first step, and to make it easier to review, it only
allows for configuring builds on the platform that is easiest to
configure for: Linux.
The CMake script checks whether the headers are present(eg. libgen.h),
whether the functions are present(eg. memmem), whether the funtions work
properly (eg. snprintf) and generate the required compile definitions
for the platform. The script also searches for the required libraries,
if it fails to find the required libraries the respective executables
won't be built.(eg. If libcurl is not found then git-remote-http won't
be built). This will help building Git easier.
With a CMake script an out of source build of git is possible resulting
in a clean source tree.
Note: this patch asks for the minimum version v3.14 of CMake (which is
not all that old as of time of writing) because that is the first
version to offer a platform-independent way to generate hardlinks as
part of the build. This is needed to generate all those hardlinks for
the built-in commands of Git.
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-12 20:29:19 +02:00
|
|
|
if(NOT Intl_FOUND)
|
|
|
|
|
add_compile_definitions(NO_GETTEXT)
|
|
|
|
|
if(NOT Iconv_FOUND)
|
|
|
|
|
add_compile_definitions(NO_ICONV)
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
include_directories(SYSTEM ${ZLIB_INCLUDE_DIRS})
|
|
|
|
|
if(CURL_FOUND)
|
|
|
|
|
include_directories(SYSTEM ${CURL_INCLUDE_DIRS})
|
|
|
|
|
endif()
|
|
|
|
|
if(EXPAT_FOUND)
|
|
|
|
|
include_directories(SYSTEM ${EXPAT_INCLUDE_DIRS})
|
|
|
|
|
endif()
|
|
|
|
|
if(Iconv_FOUND)
|
|
|
|
|
include_directories(SYSTEM ${Iconv_INCLUDE_DIRS})
|
|
|
|
|
endif()
|
|
|
|
|
if(Intl_FOUND)
|
|
|
|
|
include_directories(SYSTEM ${Intl_INCLUDE_DIRS})
|
|
|
|
|
endif()
|
|
|
|
|
|
2020-06-26 18:11:36 +02:00
|
|
|
|
2020-06-26 18:11:37 +02:00
|
|
|
if(WIN32 AND NOT MSVC)#not required for visual studio builds
|
2020-06-26 18:11:36 +02:00
|
|
|
find_program(WINDRES_EXE windres)
|
|
|
|
|
if(NOT WINDRES_EXE)
|
|
|
|
|
message(FATAL_ERROR "Install windres on Windows for resource files")
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
2021-06-06 14:02:54 +02:00
|
|
|
if(NO_GETTEXT)
|
|
|
|
|
message(STATUS "msgfmt not used under NO_GETTEXT")
|
|
|
|
|
else()
|
|
|
|
|
find_program(MSGFMT_EXE msgfmt)
|
|
|
|
|
if(NOT MSGFMT_EXE)
|
|
|
|
|
if(USE_VCPKG)
|
|
|
|
|
set(MSGFMT_EXE ${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg/downloads/tools/msys2/msys64/usr/bin/msgfmt.exe)
|
|
|
|
|
endif()
|
|
|
|
|
if(NOT EXISTS ${MSGFMT_EXE})
|
|
|
|
|
message(WARNING "Text Translations won't be built")
|
|
|
|
|
unset(MSGFMT_EXE)
|
|
|
|
|
endif()
|
2020-09-30 17:26:18 +02:00
|
|
|
endif()
|
2020-06-26 18:11:32 +02:00
|
|
|
endif()
|
|
|
|
|
|
2020-06-26 18:11:37 +02:00
|
|
|
#Force all visual studio outputs to CMAKE_BINARY_DIR
|
|
|
|
|
if(CMAKE_C_COMPILER_ID STREQUAL "MSVC")
|
|
|
|
|
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG ${CMAKE_BINARY_DIR})
|
|
|
|
|
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE ${CMAKE_BINARY_DIR})
|
|
|
|
|
add_compile_options(/MP)
|
|
|
|
|
endif()
|
|
|
|
|
|
Introduce CMake support for configuring Git
At the moment, the recommended way to configure Git's builds is to
simply run `make`. If that does not work, the recommended strategy is to
look at the top of the `Makefile` to see whether any "Makefile knob" has
to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`.
Alternatively, Git also has an `autoconf` setup which allows configuring
builds via `./configure [<option>...]`.
Both of these options are fine if the developer works on Unix or Linux.
But on Windows, we have to jump through hoops to configure a build
(read: we force the user to install a full Git for Windows SDK, which
occupies around two gigabytes (!) on disk and downloads about three
quarters of a gigabyte worth of Git objects).
The build infrastructure for Git is written around being able to run
make, which is not supported natively on Windows.
To help Windows developers a CMake build script is introduced here.
With a working support CMake, developers on Windows need only install
CMake, configure their build, load the generated Visual Studio solution
and immediately start modifying the code and build their own version of
Git. Likewise, developers on other platforms can use the convenient GUI
tools provided by CMake to configure their build.
So let's start building CMake support for Git.
This is only the first step, and to make it easier to review, it only
allows for configuring builds on the platform that is easiest to
configure for: Linux.
The CMake script checks whether the headers are present(eg. libgen.h),
whether the functions are present(eg. memmem), whether the funtions work
properly (eg. snprintf) and generate the required compile definitions
for the platform. The script also searches for the required libraries,
if it fails to find the required libraries the respective executables
won't be built.(eg. If libcurl is not found then git-remote-http won't
be built). This will help building Git easier.
With a CMake script an out of source build of git is possible resulting
in a clean source tree.
Note: this patch asks for the minimum version v3.14 of CMake (which is
not all that old as of time of writing) because that is the first
version to offer a platform-independent way to generate hardlinks as
part of the build. This is needed to generate all those hardlinks for
the built-in commands of Git.
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-12 20:29:19 +02:00
|
|
|
#default behaviour
|
|
|
|
|
include_directories(${CMAKE_SOURCE_DIR})
|
|
|
|
|
add_compile_definitions(GIT_HOST_CPU="${CMAKE_SYSTEM_PROCESSOR}")
|
|
|
|
|
add_compile_definitions(SHA256_BLK INTERNAL_QSORT RUNTIME_PREFIX)
|
|
|
|
|
add_compile_definitions(NO_OPENSSL SHA1_DC SHA1DC_NO_STANDARD_INCLUDES
|
|
|
|
|
SHA1DC_INIT_SAFE_HASH_DEFAULT=0
|
|
|
|
|
SHA1DC_CUSTOM_INCLUDE_SHA1_C="cache.h"
|
|
|
|
|
SHA1DC_CUSTOM_INCLUDE_UBC_CHECK_C="git-compat-util.h" )
|
|
|
|
|
list(APPEND compat_SOURCES sha1dc_git.c sha1dc/sha1.c sha1dc/ubc_check.c block-sha1/sha1.c sha256/block/sha256.c compat/qsort_s.c)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
add_compile_definitions(PAGER_ENV="LESS=FRX LV=-c"
|
|
|
|
|
GIT_EXEC_PATH="libexec/git-core"
|
|
|
|
|
GIT_LOCALE_PATH="share/locale"
|
|
|
|
|
GIT_MAN_PATH="share/man"
|
|
|
|
|
GIT_INFO_PATH="share/info"
|
|
|
|
|
GIT_HTML_PATH="share/doc/git-doc"
|
|
|
|
|
DEFAULT_HELP_FORMAT="html"
|
|
|
|
|
DEFAULT_GIT_TEMPLATE_DIR="share/git-core/templates"
|
|
|
|
|
GIT_VERSION="${PROJECT_VERSION}.GIT"
|
|
|
|
|
GIT_USER_AGENT="git/${PROJECT_VERSION}.GIT"
|
|
|
|
|
BINDIR="bin"
|
|
|
|
|
GIT_BUILT_FROM_COMMIT="")
|
|
|
|
|
|
2020-06-26 18:11:36 +02:00
|
|
|
if(WIN32)
|
|
|
|
|
set(FALLBACK_RUNTIME_PREFIX /mingw64)
|
2021-06-22 12:46:47 +02:00
|
|
|
# Move system config into top-level /etc/
|
|
|
|
|
add_compile_definitions(FALLBACK_RUNTIME_PREFIX="${FALLBACK_RUNTIME_PREFIX}"
|
|
|
|
|
ETC_GITATTRIBUTES="../etc/gitattributes"
|
|
|
|
|
ETC_GITCONFIG="../etc/gitconfig")
|
2020-06-26 18:11:36 +02:00
|
|
|
else()
|
|
|
|
|
set(FALLBACK_RUNTIME_PREFIX /home/$ENV{USER})
|
2021-06-22 12:46:47 +02:00
|
|
|
add_compile_definitions(FALLBACK_RUNTIME_PREFIX="${FALLBACK_RUNTIME_PREFIX}"
|
|
|
|
|
ETC_GITATTRIBUTES="etc/gitattributes"
|
|
|
|
|
ETC_GITCONFIG="etc/gitconfig")
|
2020-06-26 18:11:36 +02:00
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#Platform Specific
|
|
|
|
|
if(CMAKE_SYSTEM_NAME STREQUAL "Windows")
|
2020-06-26 18:11:37 +02:00
|
|
|
if(CMAKE_C_COMPILER_ID STREQUAL "MSVC" OR CMAKE_C_COMPILER_ID STREQUAL "Clang")
|
|
|
|
|
include_directories(${CMAKE_SOURCE_DIR}/compat/vcbuild/include)
|
|
|
|
|
add_compile_definitions(_CRT_SECURE_NO_WARNINGS _CRT_NONSTDC_NO_DEPRECATE)
|
|
|
|
|
endif()
|
2020-06-26 18:11:36 +02:00
|
|
|
include_directories(${CMAKE_SOURCE_DIR}/compat/win32)
|
|
|
|
|
add_compile_definitions(HAVE_ALLOCA_H NO_POSIX_GOODIES NATIVE_CRLF NO_UNIX_SOCKETS WIN32
|
|
|
|
|
_CONSOLE DETECT_MSYS_TTY STRIP_EXTENSION=".exe" NO_SYMLINK_HEAD UNRELIABLE_FSTAT
|
|
|
|
|
NOGDI OBJECT_CREATION_MODE=1 __USE_MINGW_ANSI_STDIO=0
|
|
|
|
|
USE_NED_ALLOCATOR OVERRIDE_STRDUP MMAP_PREVENTS_DELETE USE_WIN32_MMAP
|
|
|
|
|
UNICODE _UNICODE HAVE_WPGMPTR ENSURE_MSYSTEM_IS_SET)
|
|
|
|
|
list(APPEND compat_SOURCES compat/mingw.c compat/winansi.c compat/win32/path-utils.c
|
|
|
|
|
compat/win32/pthread.c compat/win32mmap.c compat/win32/syslog.c
|
|
|
|
|
compat/win32/trace2_win32_process_info.c compat/win32/dirent.c
|
|
|
|
|
compat/nedmalloc/nedmalloc.c compat/strdup.c)
|
|
|
|
|
set(NO_UNIX_SOCKETS 1)
|
|
|
|
|
|
|
|
|
|
elseif(CMAKE_SYSTEM_NAME STREQUAL "Linux")
|
|
|
|
|
add_compile_definitions(PROCFS_EXECUTABLE_PATH="/proc/self/exe" HAVE_DEV_TTY )
|
2021-03-15 22:08:27 +01:00
|
|
|
list(APPEND compat_SOURCES unix-socket.c unix-stream-server.c)
|
2020-06-26 18:11:36 +02:00
|
|
|
endif()
|
Introduce CMake support for configuring Git
At the moment, the recommended way to configure Git's builds is to
simply run `make`. If that does not work, the recommended strategy is to
look at the top of the `Makefile` to see whether any "Makefile knob" has
to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`.
Alternatively, Git also has an `autoconf` setup which allows configuring
builds via `./configure [<option>...]`.
Both of these options are fine if the developer works on Unix or Linux.
But on Windows, we have to jump through hoops to configure a build
(read: we force the user to install a full Git for Windows SDK, which
occupies around two gigabytes (!) on disk and downloads about three
quarters of a gigabyte worth of Git objects).
The build infrastructure for Git is written around being able to run
make, which is not supported natively on Windows.
To help Windows developers a CMake build script is introduced here.
With a working support CMake, developers on Windows need only install
CMake, configure their build, load the generated Visual Studio solution
and immediately start modifying the code and build their own version of
Git. Likewise, developers on other platforms can use the convenient GUI
tools provided by CMake to configure their build.
So let's start building CMake support for Git.
This is only the first step, and to make it easier to review, it only
allows for configuring builds on the platform that is easiest to
configure for: Linux.
The CMake script checks whether the headers are present(eg. libgen.h),
whether the functions are present(eg. memmem), whether the funtions work
properly (eg. snprintf) and generate the required compile definitions
for the platform. The script also searches for the required libraries,
if it fails to find the required libraries the respective executables
won't be built.(eg. If libcurl is not found then git-remote-http won't
be built). This will help building Git easier.
With a CMake script an out of source build of git is possible resulting
in a clean source tree.
Note: this patch asks for the minimum version v3.14 of CMake (which is
not all that old as of time of writing) because that is the first
version to offer a platform-independent way to generate hardlinks as
part of the build. This is needed to generate all those hardlinks for
the built-in commands of Git.
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-12 20:29:19 +02:00
|
|
|
|
2021-03-15 22:08:23 +01:00
|
|
|
if(CMAKE_SYSTEM_NAME STREQUAL "Windows")
|
|
|
|
|
list(APPEND compat_SOURCES compat/simple-ipc/ipc-shared.c compat/simple-ipc/ipc-win32.c)
|
2021-05-20 20:28:10 +02:00
|
|
|
add_compile_definitions(SUPPORTS_SIMPLE_IPC)
|
|
|
|
|
set(SUPPORTS_SIMPLE_IPC 1)
|
2021-03-22 11:29:47 +01:00
|
|
|
else()
|
2021-05-20 20:28:10 +02:00
|
|
|
# Simple IPC requires both Unix sockets and pthreads on Unix-based systems.
|
|
|
|
|
if(NOT NO_UNIX_SOCKETS AND NOT NO_PTHREADS)
|
|
|
|
|
list(APPEND compat_SOURCES compat/simple-ipc/ipc-shared.c compat/simple-ipc/ipc-unix-socket.c)
|
|
|
|
|
add_compile_definitions(SUPPORTS_SIMPLE_IPC)
|
|
|
|
|
set(SUPPORTS_SIMPLE_IPC 1)
|
|
|
|
|
endif()
|
2020-06-26 18:11:36 +02:00
|
|
|
endif()
|
Introduce CMake support for configuring Git
At the moment, the recommended way to configure Git's builds is to
simply run `make`. If that does not work, the recommended strategy is to
look at the top of the `Makefile` to see whether any "Makefile knob" has
to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`.
Alternatively, Git also has an `autoconf` setup which allows configuring
builds via `./configure [<option>...]`.
Both of these options are fine if the developer works on Unix or Linux.
But on Windows, we have to jump through hoops to configure a build
(read: we force the user to install a full Git for Windows SDK, which
occupies around two gigabytes (!) on disk and downloads about three
quarters of a gigabyte worth of Git objects).
The build infrastructure for Git is written around being able to run
make, which is not supported natively on Windows.
To help Windows developers a CMake build script is introduced here.
With a working support CMake, developers on Windows need only install
CMake, configure their build, load the generated Visual Studio solution
and immediately start modifying the code and build their own version of
Git. Likewise, developers on other platforms can use the convenient GUI
tools provided by CMake to configure their build.
So let's start building CMake support for Git.
This is only the first step, and to make it easier to review, it only
allows for configuring builds on the platform that is easiest to
configure for: Linux.
The CMake script checks whether the headers are present(eg. libgen.h),
whether the functions are present(eg. memmem), whether the funtions work
properly (eg. snprintf) and generate the required compile definitions
for the platform. The script also searches for the required libraries,
if it fails to find the required libraries the respective executables
won't be built.(eg. If libcurl is not found then git-remote-http won't
be built). This will help building Git easier.
With a CMake script an out of source build of git is possible resulting
in a clean source tree.
Note: this patch asks for the minimum version v3.14 of CMake (which is
not all that old as of time of writing) because that is the first
version to offer a platform-independent way to generate hardlinks as
part of the build. This is needed to generate all those hardlinks for
the built-in commands of Git.
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-12 20:29:19 +02:00
|
|
|
|
2020-06-26 18:11:36 +02:00
|
|
|
set(EXE_EXTENSION ${CMAKE_EXECUTABLE_SUFFIX})
|
Introduce CMake support for configuring Git
At the moment, the recommended way to configure Git's builds is to
simply run `make`. If that does not work, the recommended strategy is to
look at the top of the `Makefile` to see whether any "Makefile knob" has
to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`.
Alternatively, Git also has an `autoconf` setup which allows configuring
builds via `./configure [<option>...]`.
Both of these options are fine if the developer works on Unix or Linux.
But on Windows, we have to jump through hoops to configure a build
(read: we force the user to install a full Git for Windows SDK, which
occupies around two gigabytes (!) on disk and downloads about three
quarters of a gigabyte worth of Git objects).
The build infrastructure for Git is written around being able to run
make, which is not supported natively on Windows.
To help Windows developers a CMake build script is introduced here.
With a working support CMake, developers on Windows need only install
CMake, configure their build, load the generated Visual Studio solution
and immediately start modifying the code and build their own version of
Git. Likewise, developers on other platforms can use the convenient GUI
tools provided by CMake to configure their build.
So let's start building CMake support for Git.
This is only the first step, and to make it easier to review, it only
allows for configuring builds on the platform that is easiest to
configure for: Linux.
The CMake script checks whether the headers are present(eg. libgen.h),
whether the functions are present(eg. memmem), whether the funtions work
properly (eg. snprintf) and generate the required compile definitions
for the platform. The script also searches for the required libraries,
if it fails to find the required libraries the respective executables
won't be built.(eg. If libcurl is not found then git-remote-http won't
be built). This will help building Git easier.
With a CMake script an out of source build of git is possible resulting
in a clean source tree.
Note: this patch asks for the minimum version v3.14 of CMake (which is
not all that old as of time of writing) because that is the first
version to offer a platform-independent way to generate hardlinks as
part of the build. This is needed to generate all those hardlinks for
the built-in commands of Git.
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-12 20:29:19 +02:00
|
|
|
|
|
|
|
|
#header checks
|
|
|
|
|
check_include_file(libgen.h HAVE_LIBGEN_H)
|
|
|
|
|
if(NOT HAVE_LIBGEN_H)
|
|
|
|
|
add_compile_definitions(NO_LIBGEN_H)
|
|
|
|
|
list(APPEND compat_SOURCES compat/basename.c)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
check_include_file(sys/sysinfo.h HAVE_SYSINFO)
|
|
|
|
|
if(HAVE_SYSINFO)
|
|
|
|
|
add_compile_definitions(HAVE_SYSINFO)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
check_c_source_compiles("
|
|
|
|
|
#include <alloca.h>
|
|
|
|
|
|
|
|
|
|
int main(void)
|
|
|
|
|
{
|
|
|
|
|
char *p = (char *) alloca(2 * sizeof(int));
|
|
|
|
|
|
|
|
|
|
if (p)
|
|
|
|
|
return 0;
|
|
|
|
|
return 0;
|
|
|
|
|
}"
|
|
|
|
|
HAVE_ALLOCA_H)
|
|
|
|
|
if(HAVE_ALLOCA_H)
|
|
|
|
|
add_compile_definitions(HAVE_ALLOCA_H)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
check_include_file(strings.h HAVE_STRINGS_H)
|
|
|
|
|
if(HAVE_STRINGS_H)
|
|
|
|
|
add_compile_definitions(HAVE_STRINGS_H)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
check_include_file(sys/select.h HAVE_SYS_SELECT_H)
|
|
|
|
|
if(NOT HAVE_SYS_SELECT_H)
|
|
|
|
|
add_compile_definitions(NO_SYS_SELECT_H)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
check_include_file(sys/poll.h HAVE_SYS_POLL_H)
|
|
|
|
|
if(NOT HAVE_SYS_POLL_H)
|
|
|
|
|
add_compile_definitions(NO_SYS_POLL_H)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
check_include_file(poll.h HAVE_POLL_H)
|
|
|
|
|
if(NOT HAVE_POLL_H)
|
|
|
|
|
add_compile_definitions(NO_POLL_H)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
check_include_file(inttypes.h HAVE_INTTYPES_H)
|
|
|
|
|
if(NOT HAVE_INTTYPES_H)
|
|
|
|
|
add_compile_definitions(NO_INTTYPES_H)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
check_include_file(paths.h HAVE_PATHS_H)
|
|
|
|
|
if(HAVE_PATHS_H)
|
|
|
|
|
add_compile_definitions(HAVE_PATHS_H)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
#function checks
|
|
|
|
|
set(function_checks
|
|
|
|
|
strcasestr memmem strlcpy strtoimax strtoumax strtoull
|
2020-06-26 18:11:36 +02:00
|
|
|
setenv mkdtemp poll pread memmem)
|
|
|
|
|
|
|
|
|
|
#unsetenv,hstrerror are incompatible with windows build
|
|
|
|
|
if(NOT WIN32)
|
|
|
|
|
list(APPEND function_checks unsetenv hstrerror)
|
|
|
|
|
endif()
|
Introduce CMake support for configuring Git
At the moment, the recommended way to configure Git's builds is to
simply run `make`. If that does not work, the recommended strategy is to
look at the top of the `Makefile` to see whether any "Makefile knob" has
to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`.
Alternatively, Git also has an `autoconf` setup which allows configuring
builds via `./configure [<option>...]`.
Both of these options are fine if the developer works on Unix or Linux.
But on Windows, we have to jump through hoops to configure a build
(read: we force the user to install a full Git for Windows SDK, which
occupies around two gigabytes (!) on disk and downloads about three
quarters of a gigabyte worth of Git objects).
The build infrastructure for Git is written around being able to run
make, which is not supported natively on Windows.
To help Windows developers a CMake build script is introduced here.
With a working support CMake, developers on Windows need only install
CMake, configure their build, load the generated Visual Studio solution
and immediately start modifying the code and build their own version of
Git. Likewise, developers on other platforms can use the convenient GUI
tools provided by CMake to configure their build.
So let's start building CMake support for Git.
This is only the first step, and to make it easier to review, it only
allows for configuring builds on the platform that is easiest to
configure for: Linux.
The CMake script checks whether the headers are present(eg. libgen.h),
whether the functions are present(eg. memmem), whether the funtions work
properly (eg. snprintf) and generate the required compile definitions
for the platform. The script also searches for the required libraries,
if it fails to find the required libraries the respective executables
won't be built.(eg. If libcurl is not found then git-remote-http won't
be built). This will help building Git easier.
With a CMake script an out of source build of git is possible resulting
in a clean source tree.
Note: this patch asks for the minimum version v3.14 of CMake (which is
not all that old as of time of writing) because that is the first
version to offer a platform-independent way to generate hardlinks as
part of the build. This is needed to generate all those hardlinks for
the built-in commands of Git.
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-12 20:29:19 +02:00
|
|
|
|
|
|
|
|
foreach(f ${function_checks})
|
|
|
|
|
string(TOUPPER ${f} uf)
|
|
|
|
|
check_function_exists(${f} HAVE_${uf})
|
|
|
|
|
if(NOT HAVE_${uf})
|
|
|
|
|
add_compile_definitions(NO_${uf})
|
|
|
|
|
endif()
|
|
|
|
|
endforeach()
|
|
|
|
|
|
|
|
|
|
if(NOT HAVE_POLL_H OR NOT HAVE_SYS_POLL_H OR NOT HAVE_POLL)
|
|
|
|
|
include_directories(${CMAKE_SOURCE_DIR}/compat/poll)
|
|
|
|
|
add_compile_definitions(NO_POLL)
|
|
|
|
|
list(APPEND compat_SOURCES compat/poll/poll.c)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(NOT HAVE_STRCASESTR)
|
|
|
|
|
list(APPEND compat_SOURCES compat/strcasestr.c)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(NOT HAVE_STRLCPY)
|
|
|
|
|
list(APPEND compat_SOURCES compat/strlcpy.c)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(NOT HAVE_STRTOUMAX)
|
|
|
|
|
list(APPEND compat_SOURCES compat/strtoumax.c compat/strtoimax.c)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(NOT HAVE_SETENV)
|
|
|
|
|
list(APPEND compat_SOURCES compat/setenv.c)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(NOT HAVE_MKDTEMP)
|
|
|
|
|
list(APPEND compat_SOURCES compat/mkdtemp.c)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(NOT HAVE_PREAD)
|
|
|
|
|
list(APPEND compat_SOURCES compat/pread.c)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(NOT HAVE_MEMMEM)
|
|
|
|
|
list(APPEND compat_SOURCES compat/memmem.c)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(NOT WIN32)
|
|
|
|
|
if(NOT HAVE_UNSETENV)
|
|
|
|
|
list(APPEND compat_SOURCES compat/unsetenv.c)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(NOT HAVE_HSTRERROR)
|
|
|
|
|
list(APPEND compat_SOURCES compat/hstrerror.c)
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
check_function_exists(getdelim HAVE_GETDELIM)
|
|
|
|
|
if(HAVE_GETDELIM)
|
|
|
|
|
add_compile_definitions(HAVE_GETDELIM)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
check_function_exists(clock_gettime HAVE_CLOCK_GETTIME)
|
|
|
|
|
check_symbol_exists(CLOCK_MONOTONIC "time.h" HAVE_CLOCK_MONOTONIC)
|
|
|
|
|
if(HAVE_CLOCK_GETTIME)
|
|
|
|
|
add_compile_definitions(HAVE_CLOCK_GETTIME)
|
|
|
|
|
endif()
|
|
|
|
|
if(HAVE_CLOCK_MONOTONIC)
|
|
|
|
|
add_compile_definitions(HAVE_CLOCK_MONOTONIC)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
#check for st_blocks in struct stat
|
|
|
|
|
check_struct_has_member("struct stat" st_blocks "sys/stat.h" STRUCT_STAT_HAS_ST_BLOCKS)
|
|
|
|
|
if(NOT STRUCT_STAT_HAS_ST_BLOCKS)
|
|
|
|
|
add_compile_definitions(NO_ST_BLOCKS_IN_STRUCT_STAT)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
#compile checks
|
|
|
|
|
check_c_source_runs("
|
|
|
|
|
#include<stdio.h>
|
|
|
|
|
#include<stdarg.h>
|
|
|
|
|
#include<string.h>
|
|
|
|
|
#include<stdlib.h>
|
|
|
|
|
|
|
|
|
|
int test_vsnprintf(char *str, size_t maxsize, const char *format, ...)
|
|
|
|
|
{
|
|
|
|
|
int ret;
|
|
|
|
|
va_list ap;
|
|
|
|
|
|
|
|
|
|
va_start(ap, format);
|
|
|
|
|
ret = vsnprintf(str, maxsize, format, ap);
|
|
|
|
|
va_end(ap);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int main(void)
|
|
|
|
|
{
|
|
|
|
|
char buf[6];
|
|
|
|
|
|
|
|
|
|
if (test_vsnprintf(buf, 3, \"%s\", \"12345\") != 5
|
|
|
|
|
|| strcmp(buf, \"12\"))
|
|
|
|
|
return 1;
|
|
|
|
|
if (snprintf(buf, 3, \"%s\", \"12345\") != 5
|
|
|
|
|
|| strcmp(buf, \"12\"))
|
|
|
|
|
return 1;
|
|
|
|
|
return 0;
|
|
|
|
|
}"
|
|
|
|
|
SNPRINTF_OK)
|
|
|
|
|
if(NOT SNPRINTF_OK)
|
|
|
|
|
add_compile_definitions(SNPRINTF_RETURNS_BOGUS)
|
|
|
|
|
list(APPEND compat_SOURCES compat/snprintf.c)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
check_c_source_runs("
|
|
|
|
|
#include<stdio.h>
|
|
|
|
|
|
|
|
|
|
int main(void)
|
|
|
|
|
{
|
|
|
|
|
FILE *f = fopen(\".\", \"r\");
|
|
|
|
|
|
|
|
|
|
return f != NULL;
|
|
|
|
|
}"
|
|
|
|
|
FREAD_READS_DIRECTORIES_NO)
|
|
|
|
|
if(NOT FREAD_READS_DIRECTORIES_NO)
|
|
|
|
|
add_compile_definitions(FREAD_READS_DIRECTORIES)
|
|
|
|
|
list(APPEND compat_SOURCES compat/fopen.c)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
check_c_source_compiles("
|
|
|
|
|
#include <regex.h>
|
|
|
|
|
#ifndef REG_STARTEND
|
|
|
|
|
#error oops we dont have it
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
int main(void)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}"
|
|
|
|
|
HAVE_REGEX)
|
|
|
|
|
if(NOT HAVE_REGEX)
|
|
|
|
|
include_directories(${CMAKE_SOURCE_DIR}/compat/regex)
|
|
|
|
|
list(APPEND compat_SOURCES compat/regex/regex.c )
|
|
|
|
|
add_compile_definitions(NO_REGEX NO_MBSUPPORT GAWK)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
check_c_source_compiles("
|
|
|
|
|
#include <stddef.h>
|
|
|
|
|
#include <sys/types.h>
|
|
|
|
|
#include <sys/sysctl.h>
|
|
|
|
|
|
|
|
|
|
int main(void)
|
|
|
|
|
{
|
|
|
|
|
int val, mib[2];
|
|
|
|
|
size_t len;
|
|
|
|
|
|
|
|
|
|
mib[0] = CTL_HW;
|
|
|
|
|
mib[1] = 1;
|
|
|
|
|
len = sizeof(val);
|
|
|
|
|
return sysctl(mib, 2, &val, &len, NULL, 0) ? 1 : 0;
|
|
|
|
|
}"
|
|
|
|
|
HAVE_BSD_SYSCTL)
|
|
|
|
|
if(HAVE_BSD_SYSCTL)
|
|
|
|
|
add_compile_definitions(HAVE_BSD_SYSCTL)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
set(CMAKE_REQUIRED_LIBRARIES ${Iconv_LIBRARIES})
|
|
|
|
|
set(CMAKE_REQUIRED_INCLUDES ${Iconv_INCLUDE_DIRS})
|
|
|
|
|
|
|
|
|
|
check_c_source_compiles("
|
|
|
|
|
#include <iconv.h>
|
|
|
|
|
|
|
|
|
|
extern size_t iconv(iconv_t cd,
|
|
|
|
|
char **inbuf, size_t *inbytesleft,
|
|
|
|
|
char **outbuf, size_t *outbytesleft);
|
|
|
|
|
|
|
|
|
|
int main(void)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}"
|
|
|
|
|
HAVE_NEW_ICONV)
|
|
|
|
|
if(HAVE_NEW_ICONV)
|
|
|
|
|
set(HAVE_OLD_ICONV 0)
|
|
|
|
|
else()
|
|
|
|
|
set(HAVE_OLD_ICONV 1)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
check_c_source_runs("
|
|
|
|
|
#include <iconv.h>
|
|
|
|
|
#if ${HAVE_OLD_ICONV}
|
|
|
|
|
typedef const char *iconv_ibp;
|
|
|
|
|
#else
|
|
|
|
|
typedef char *iconv_ibp;
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
int main(void)
|
|
|
|
|
{
|
|
|
|
|
int v;
|
|
|
|
|
iconv_t conv;
|
|
|
|
|
char in[] = \"a\";
|
|
|
|
|
iconv_ibp pin = in;
|
|
|
|
|
char out[20] = \"\";
|
|
|
|
|
char *pout = out;
|
|
|
|
|
size_t isz = sizeof(in);
|
|
|
|
|
size_t osz = sizeof(out);
|
|
|
|
|
|
|
|
|
|
conv = iconv_open(\"UTF-16\", \"UTF-8\");
|
|
|
|
|
iconv(conv, &pin, &isz, &pout, &osz);
|
|
|
|
|
iconv_close(conv);
|
|
|
|
|
v = (unsigned char)(out[0]) + (unsigned char)(out[1]);
|
|
|
|
|
return v != 0xfe + 0xff;
|
|
|
|
|
}"
|
|
|
|
|
ICONV_DOESNOT_OMIT_BOM)
|
|
|
|
|
if(NOT ICONV_DOESNOT_OMIT_BOM)
|
|
|
|
|
add_compile_definitions(ICONV_OMITS_BOM)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
unset(CMAKE_REQUIRED_LIBRARIES)
|
|
|
|
|
unset(CMAKE_REQUIRED_INCLUDES)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#programs
|
|
|
|
|
set(PROGRAMS_BUILT
|
2020-08-13 16:59:45 +02:00
|
|
|
git git-daemon git-http-backend git-sh-i18n--envsubst
|
drop vcs-svn experiment
The code in vcs-svn was started in 2010 as an attempt to build a
remote-helper for interacting with svn repositories (as opposed to
git-svn). However, we never got as far as shipping a mature remote
helper, and the last substantive commit was e99d012a6bc in 2012.
We do have a git-remote-testsvn, and it is even installed as part of
"make install". But given the name, it seems unlikely to be used by
anybody (you'd have to explicitly "git clone testsvn::$url", and there
have been zero mentions of that on the mailing list since 2013, and even
that includes the phrase "you might need to hack a bit to get it working
properly"[1]).
We also ship contrib/svn-fe, which builds on the vcs-svn work. However,
it does not seem to build out of the box for me, as the link step misses
some required libraries for using libgit.a. Curiously, the original
build breakage bisects for me to eff80a9fd9 (Allow custom "comment
char", 2013-01-16), which seems unrelated. There was an attempt to fix
it in da011cb0e7 (contrib/svn-fe: fix Makefile, 2014-08-28), but on my
system that only switches the error message.
So it seems like the result is not really usable by anybody in practice.
It would be wonderful if somebody wanted to pick up the topic again, and
potentially it's worth carrying around for that reason. But the flip
side is that people doing tree-wide operations have to deal with this
code. And you can see the list with (replace "HEAD" with this commit as
appropriate):
{
echo "--"
git diff-tree --diff-filter=D -r --name-only HEAD^ HEAD
} |
git log --no-merges --oneline e99d012a6bc.. --stdin
which shows 58 times somebody had to deal with the code, generally due
to a compile or test failure, or a tree-wide style fix or API change.
Let's drop it and let anybody who wants to pick it up do so by
resurrecting it from the git history.
As a bonus, this also reduces the size of a stripped installation of Git
from 21MB to 19MB.
[1] https://lore.kernel.org/git/CALkWK0mPHzKfzFKKpZkfAus3YVC9NFYDbFnt+5JQYVKipk3bQQ@mail.gmail.com/
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-13 17:00:17 +02:00
|
|
|
git-shell)
|
2020-06-26 18:11:36 +02:00
|
|
|
|
Introduce CMake support for configuring Git
At the moment, the recommended way to configure Git's builds is to
simply run `make`. If that does not work, the recommended strategy is to
look at the top of the `Makefile` to see whether any "Makefile knob" has
to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`.
Alternatively, Git also has an `autoconf` setup which allows configuring
builds via `./configure [<option>...]`.
Both of these options are fine if the developer works on Unix or Linux.
But on Windows, we have to jump through hoops to configure a build
(read: we force the user to install a full Git for Windows SDK, which
occupies around two gigabytes (!) on disk and downloads about three
quarters of a gigabyte worth of Git objects).
The build infrastructure for Git is written around being able to run
make, which is not supported natively on Windows.
To help Windows developers a CMake build script is introduced here.
With a working support CMake, developers on Windows need only install
CMake, configure their build, load the generated Visual Studio solution
and immediately start modifying the code and build their own version of
Git. Likewise, developers on other platforms can use the convenient GUI
tools provided by CMake to configure their build.
So let's start building CMake support for Git.
This is only the first step, and to make it easier to review, it only
allows for configuring builds on the platform that is easiest to
configure for: Linux.
The CMake script checks whether the headers are present(eg. libgen.h),
whether the functions are present(eg. memmem), whether the funtions work
properly (eg. snprintf) and generate the required compile definitions
for the platform. The script also searches for the required libraries,
if it fails to find the required libraries the respective executables
won't be built.(eg. If libcurl is not found then git-remote-http won't
be built). This will help building Git easier.
With a CMake script an out of source build of git is possible resulting
in a clean source tree.
Note: this patch asks for the minimum version v3.14 of CMake (which is
not all that old as of time of writing) because that is the first
version to offer a platform-independent way to generate hardlinks as
part of the build. This is needed to generate all those hardlinks for
the built-in commands of Git.
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-12 20:29:19 +02:00
|
|
|
if(NOT CURL_FOUND)
|
|
|
|
|
list(APPEND excluded_progs git-http-fetch git-http-push)
|
|
|
|
|
add_compile_definitions(NO_CURL)
|
|
|
|
|
message(WARNING "git-http-push and git-http-fetch will not be built")
|
|
|
|
|
else()
|
|
|
|
|
list(APPEND PROGRAMS_BUILT git-http-fetch git-http-push git-imap-send git-remote-http)
|
|
|
|
|
if(CURL_VERSION_STRING VERSION_GREATER_EQUAL 7.34.0)
|
|
|
|
|
add_compile_definitions(USE_CURL_FOR_IMAP_SEND)
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(NOT EXPAT_FOUND)
|
|
|
|
|
list(APPEND excluded_progs git-http-push)
|
|
|
|
|
add_compile_definitions(NO_EXPAT)
|
|
|
|
|
else()
|
|
|
|
|
list(APPEND PROGRAMS_BUILT git-http-push)
|
|
|
|
|
if(EXPAT_VERSION_STRING VERSION_LESS_EQUAL 1.2)
|
|
|
|
|
add_compile_definitions(EXPAT_NEEDS_XMLPARSE_H)
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
list(REMOVE_DUPLICATES excluded_progs)
|
|
|
|
|
list(REMOVE_DUPLICATES PROGRAMS_BUILT)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
foreach(p ${excluded_progs})
|
|
|
|
|
list(APPEND EXCLUSION_PROGS --exclude-program ${p} )
|
|
|
|
|
endforeach()
|
|
|
|
|
|
|
|
|
|
#for comparing null values
|
|
|
|
|
list(APPEND EXCLUSION_PROGS empty)
|
|
|
|
|
set(EXCLUSION_PROGS_CACHE ${EXCLUSION_PROGS} CACHE STRING "Programs not built" FORCE)
|
|
|
|
|
|
|
|
|
|
if(NOT EXISTS ${CMAKE_BINARY_DIR}/command-list.h OR NOT EXCLUSION_PROGS_CACHE STREQUAL EXCLUSION_PROGS)
|
|
|
|
|
list(REMOVE_ITEM EXCLUSION_PROGS empty)
|
|
|
|
|
message("Generating command-list.h")
|
|
|
|
|
execute_process(COMMAND ${SH_EXE} ${CMAKE_SOURCE_DIR}/generate-cmdlist.sh ${EXCLUSION_PROGS} command-list.txt
|
|
|
|
|
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
|
|
|
|
|
OUTPUT_FILE ${CMAKE_BINARY_DIR}/command-list.h)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(NOT EXISTS ${CMAKE_BINARY_DIR}/config-list.h)
|
|
|
|
|
message("Generating config-list.h")
|
|
|
|
|
execute_process(COMMAND ${SH_EXE} ${CMAKE_SOURCE_DIR}/generate-configlist.sh
|
|
|
|
|
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
|
|
|
|
|
OUTPUT_FILE ${CMAKE_BINARY_DIR}/config-list.h)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
include_directories(${CMAKE_BINARY_DIR})
|
|
|
|
|
|
|
|
|
|
#build
|
|
|
|
|
#libgit
|
|
|
|
|
parse_makefile_for_sources(libgit_SOURCES "LIB_OBJS")
|
|
|
|
|
|
|
|
|
|
list(TRANSFORM libgit_SOURCES PREPEND "${CMAKE_SOURCE_DIR}/")
|
|
|
|
|
list(TRANSFORM compat_SOURCES PREPEND "${CMAKE_SOURCE_DIR}/")
|
|
|
|
|
add_library(libgit ${libgit_SOURCES} ${compat_SOURCES})
|
|
|
|
|
|
|
|
|
|
#libxdiff
|
|
|
|
|
parse_makefile_for_sources(libxdiff_SOURCES "XDIFF_OBJS")
|
|
|
|
|
|
|
|
|
|
list(TRANSFORM libxdiff_SOURCES PREPEND "${CMAKE_SOURCE_DIR}/")
|
|
|
|
|
add_library(xdiff STATIC ${libxdiff_SOURCES})
|
|
|
|
|
|
2020-06-26 18:11:36 +02:00
|
|
|
if(WIN32)
|
2020-06-26 18:11:37 +02:00
|
|
|
if(NOT MSVC)#use windres when compiling with gcc and clang
|
|
|
|
|
add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/git.res
|
|
|
|
|
COMMAND ${WINDRES_EXE} -O coff -DMAJOR=${PROJECT_VERSION_MAJOR} -DMINOR=${PROJECT_VERSION_MINOR}
|
|
|
|
|
-DMICRO=${PROJECT_VERSION_PATCH} -DPATCHLEVEL=0 -DGIT_VERSION="\\\"${PROJECT_VERSION}.GIT\\\""
|
|
|
|
|
-i ${CMAKE_SOURCE_DIR}/git.rc -o ${CMAKE_BINARY_DIR}/git.res
|
|
|
|
|
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
|
|
|
|
|
VERBATIM)
|
|
|
|
|
else()#MSVC use rc
|
|
|
|
|
add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/git.res
|
|
|
|
|
COMMAND ${CMAKE_RC_COMPILER} /d MAJOR=${PROJECT_VERSION_MAJOR} /d MINOR=${PROJECT_VERSION_MINOR}
|
|
|
|
|
/d MICRO=${PROJECT_VERSION_PATCH} /d PATCHLEVEL=0 /d GIT_VERSION="${PROJECT_VERSION}.GIT"
|
|
|
|
|
/fo ${CMAKE_BINARY_DIR}/git.res ${CMAKE_SOURCE_DIR}/git.rc
|
|
|
|
|
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
|
|
|
|
|
VERBATIM)
|
|
|
|
|
endif()
|
2020-06-26 18:11:36 +02:00
|
|
|
add_custom_target(git-rc DEPENDS ${CMAKE_BINARY_DIR}/git.res)
|
|
|
|
|
endif()
|
|
|
|
|
|
Introduce CMake support for configuring Git
At the moment, the recommended way to configure Git's builds is to
simply run `make`. If that does not work, the recommended strategy is to
look at the top of the `Makefile` to see whether any "Makefile knob" has
to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`.
Alternatively, Git also has an `autoconf` setup which allows configuring
builds via `./configure [<option>...]`.
Both of these options are fine if the developer works on Unix or Linux.
But on Windows, we have to jump through hoops to configure a build
(read: we force the user to install a full Git for Windows SDK, which
occupies around two gigabytes (!) on disk and downloads about three
quarters of a gigabyte worth of Git objects).
The build infrastructure for Git is written around being able to run
make, which is not supported natively on Windows.
To help Windows developers a CMake build script is introduced here.
With a working support CMake, developers on Windows need only install
CMake, configure their build, load the generated Visual Studio solution
and immediately start modifying the code and build their own version of
Git. Likewise, developers on other platforms can use the convenient GUI
tools provided by CMake to configure their build.
So let's start building CMake support for Git.
This is only the first step, and to make it easier to review, it only
allows for configuring builds on the platform that is easiest to
configure for: Linux.
The CMake script checks whether the headers are present(eg. libgen.h),
whether the functions are present(eg. memmem), whether the funtions work
properly (eg. snprintf) and generate the required compile definitions
for the platform. The script also searches for the required libraries,
if it fails to find the required libraries the respective executables
won't be built.(eg. If libcurl is not found then git-remote-http won't
be built). This will help building Git easier.
With a CMake script an out of source build of git is possible resulting
in a clean source tree.
Note: this patch asks for the minimum version v3.14 of CMake (which is
not all that old as of time of writing) because that is the first
version to offer a platform-independent way to generate hardlinks as
part of the build. This is needed to generate all those hardlinks for
the built-in commands of Git.
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-12 20:29:19 +02:00
|
|
|
#link all required libraries to common-main
|
|
|
|
|
add_library(common-main OBJECT ${CMAKE_SOURCE_DIR}/common-main.c)
|
2020-06-26 18:11:36 +02:00
|
|
|
|
|
|
|
|
target_link_libraries(common-main libgit xdiff ${ZLIB_LIBRARIES})
|
Introduce CMake support for configuring Git
At the moment, the recommended way to configure Git's builds is to
simply run `make`. If that does not work, the recommended strategy is to
look at the top of the `Makefile` to see whether any "Makefile knob" has
to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`.
Alternatively, Git also has an `autoconf` setup which allows configuring
builds via `./configure [<option>...]`.
Both of these options are fine if the developer works on Unix or Linux.
But on Windows, we have to jump through hoops to configure a build
(read: we force the user to install a full Git for Windows SDK, which
occupies around two gigabytes (!) on disk and downloads about three
quarters of a gigabyte worth of Git objects).
The build infrastructure for Git is written around being able to run
make, which is not supported natively on Windows.
To help Windows developers a CMake build script is introduced here.
With a working support CMake, developers on Windows need only install
CMake, configure their build, load the generated Visual Studio solution
and immediately start modifying the code and build their own version of
Git. Likewise, developers on other platforms can use the convenient GUI
tools provided by CMake to configure their build.
So let's start building CMake support for Git.
This is only the first step, and to make it easier to review, it only
allows for configuring builds on the platform that is easiest to
configure for: Linux.
The CMake script checks whether the headers are present(eg. libgen.h),
whether the functions are present(eg. memmem), whether the funtions work
properly (eg. snprintf) and generate the required compile definitions
for the platform. The script also searches for the required libraries,
if it fails to find the required libraries the respective executables
won't be built.(eg. If libcurl is not found then git-remote-http won't
be built). This will help building Git easier.
With a CMake script an out of source build of git is possible resulting
in a clean source tree.
Note: this patch asks for the minimum version v3.14 of CMake (which is
not all that old as of time of writing) because that is the first
version to offer a platform-independent way to generate hardlinks as
part of the build. This is needed to generate all those hardlinks for
the built-in commands of Git.
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-12 20:29:19 +02:00
|
|
|
if(Intl_FOUND)
|
|
|
|
|
target_link_libraries(common-main ${Intl_LIBRARIES})
|
|
|
|
|
endif()
|
|
|
|
|
if(Iconv_FOUND)
|
|
|
|
|
target_link_libraries(common-main ${Iconv_LIBRARIES})
|
|
|
|
|
endif()
|
2020-06-26 18:11:36 +02:00
|
|
|
if(WIN32)
|
|
|
|
|
target_link_libraries(common-main ws2_32 ntdll ${CMAKE_BINARY_DIR}/git.res)
|
|
|
|
|
add_dependencies(common-main git-rc)
|
2020-06-26 18:11:37 +02:00
|
|
|
if(CMAKE_C_COMPILER_ID STREQUAL "GNU")
|
|
|
|
|
target_link_options(common-main PUBLIC -municode -Wl,--nxcompat -Wl,--dynamicbase -Wl,--pic-executable,-e,mainCRTStartup)
|
|
|
|
|
elseif(CMAKE_C_COMPILER_ID STREQUAL "Clang")
|
|
|
|
|
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)
|
2020-09-30 17:26:21 +02:00
|
|
|
else()
|
|
|
|
|
message(FATAL_ERROR "Unhandled compiler: ${CMAKE_C_COMPILER_ID}")
|
2020-06-26 18:11:37 +02:00
|
|
|
endif()
|
2020-06-26 18:11:36 +02:00
|
|
|
elseif(UNIX)
|
|
|
|
|
target_link_libraries(common-main pthread rt)
|
|
|
|
|
endif()
|
Introduce CMake support for configuring Git
At the moment, the recommended way to configure Git's builds is to
simply run `make`. If that does not work, the recommended strategy is to
look at the top of the `Makefile` to see whether any "Makefile knob" has
to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`.
Alternatively, Git also has an `autoconf` setup which allows configuring
builds via `./configure [<option>...]`.
Both of these options are fine if the developer works on Unix or Linux.
But on Windows, we have to jump through hoops to configure a build
(read: we force the user to install a full Git for Windows SDK, which
occupies around two gigabytes (!) on disk and downloads about three
quarters of a gigabyte worth of Git objects).
The build infrastructure for Git is written around being able to run
make, which is not supported natively on Windows.
To help Windows developers a CMake build script is introduced here.
With a working support CMake, developers on Windows need only install
CMake, configure their build, load the generated Visual Studio solution
and immediately start modifying the code and build their own version of
Git. Likewise, developers on other platforms can use the convenient GUI
tools provided by CMake to configure their build.
So let's start building CMake support for Git.
This is only the first step, and to make it easier to review, it only
allows for configuring builds on the platform that is easiest to
configure for: Linux.
The CMake script checks whether the headers are present(eg. libgen.h),
whether the functions are present(eg. memmem), whether the funtions work
properly (eg. snprintf) and generate the required compile definitions
for the platform. The script also searches for the required libraries,
if it fails to find the required libraries the respective executables
won't be built.(eg. If libcurl is not found then git-remote-http won't
be built). This will help building Git easier.
With a CMake script an out of source build of git is possible resulting
in a clean source tree.
Note: this patch asks for the minimum version v3.14 of CMake (which is
not all that old as of time of writing) because that is the first
version to offer a platform-independent way to generate hardlinks as
part of the build. This is needed to generate all those hardlinks for
the built-in commands of Git.
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-12 20:29:19 +02:00
|
|
|
|
|
|
|
|
#git
|
|
|
|
|
parse_makefile_for_sources(git_SOURCES "BUILTIN_OBJS")
|
|
|
|
|
|
|
|
|
|
list(TRANSFORM git_SOURCES PREPEND "${CMAKE_SOURCE_DIR}/")
|
|
|
|
|
add_executable(git ${CMAKE_SOURCE_DIR}/git.c ${git_SOURCES})
|
|
|
|
|
target_link_libraries(git common-main)
|
|
|
|
|
|
|
|
|
|
add_executable(git-daemon ${CMAKE_SOURCE_DIR}/daemon.c)
|
|
|
|
|
target_link_libraries(git-daemon common-main)
|
|
|
|
|
|
|
|
|
|
add_executable(git-http-backend ${CMAKE_SOURCE_DIR}/http-backend.c)
|
|
|
|
|
target_link_libraries(git-http-backend common-main)
|
|
|
|
|
|
|
|
|
|
add_executable(git-sh-i18n--envsubst ${CMAKE_SOURCE_DIR}/sh-i18n--envsubst.c)
|
|
|
|
|
target_link_libraries(git-sh-i18n--envsubst common-main)
|
|
|
|
|
|
|
|
|
|
add_executable(git-shell ${CMAKE_SOURCE_DIR}/shell.c)
|
|
|
|
|
target_link_libraries(git-shell common-main)
|
|
|
|
|
|
|
|
|
|
if(CURL_FOUND)
|
|
|
|
|
add_library(http_obj OBJECT ${CMAKE_SOURCE_DIR}/http.c)
|
|
|
|
|
|
|
|
|
|
add_executable(git-imap-send ${CMAKE_SOURCE_DIR}/imap-send.c)
|
|
|
|
|
target_link_libraries(git-imap-send http_obj common-main ${CURL_LIBRARIES})
|
|
|
|
|
|
|
|
|
|
add_executable(git-http-fetch ${CMAKE_SOURCE_DIR}/http-walker.c ${CMAKE_SOURCE_DIR}/http-fetch.c)
|
|
|
|
|
target_link_libraries(git-http-fetch http_obj common-main ${CURL_LIBRARIES})
|
|
|
|
|
|
|
|
|
|
add_executable(git-remote-http ${CMAKE_SOURCE_DIR}/http-walker.c ${CMAKE_SOURCE_DIR}/remote-curl.c)
|
|
|
|
|
target_link_libraries(git-remote-http http_obj common-main ${CURL_LIBRARIES} )
|
|
|
|
|
|
|
|
|
|
if(EXPAT_FOUND)
|
|
|
|
|
add_executable(git-http-push ${CMAKE_SOURCE_DIR}/http-push.c)
|
|
|
|
|
target_link_libraries(git-http-push http_obj common-main ${CURL_LIBRARIES} ${EXPAT_LIBRARIES})
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
2020-12-04 20:33:56 +01:00
|
|
|
parse_makefile_for_executables(git_builtin_extra "BUILT_INS")
|
Introduce CMake support for configuring Git
At the moment, the recommended way to configure Git's builds is to
simply run `make`. If that does not work, the recommended strategy is to
look at the top of the `Makefile` to see whether any "Makefile knob" has
to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`.
Alternatively, Git also has an `autoconf` setup which allows configuring
builds via `./configure [<option>...]`.
Both of these options are fine if the developer works on Unix or Linux.
But on Windows, we have to jump through hoops to configure a build
(read: we force the user to install a full Git for Windows SDK, which
occupies around two gigabytes (!) on disk and downloads about three
quarters of a gigabyte worth of Git objects).
The build infrastructure for Git is written around being able to run
make, which is not supported natively on Windows.
To help Windows developers a CMake build script is introduced here.
With a working support CMake, developers on Windows need only install
CMake, configure their build, load the generated Visual Studio solution
and immediately start modifying the code and build their own version of
Git. Likewise, developers on other platforms can use the convenient GUI
tools provided by CMake to configure their build.
So let's start building CMake support for Git.
This is only the first step, and to make it easier to review, it only
allows for configuring builds on the platform that is easiest to
configure for: Linux.
The CMake script checks whether the headers are present(eg. libgen.h),
whether the functions are present(eg. memmem), whether the funtions work
properly (eg. snprintf) and generate the required compile definitions
for the platform. The script also searches for the required libraries,
if it fails to find the required libraries the respective executables
won't be built.(eg. If libcurl is not found then git-remote-http won't
be built). This will help building Git easier.
With a CMake script an out of source build of git is possible resulting
in a clean source tree.
Note: this patch asks for the minimum version v3.14 of CMake (which is
not all that old as of time of writing) because that is the first
version to offer a platform-independent way to generate hardlinks as
part of the build. This is needed to generate all those hardlinks for
the built-in commands of Git.
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-12 20:29:19 +02:00
|
|
|
|
2021-03-28 00:06:22 +01:00
|
|
|
option(SKIP_DASHED_BUILT_INS "Skip hardlinking the dashed versions of the built-ins")
|
|
|
|
|
|
Introduce CMake support for configuring Git
At the moment, the recommended way to configure Git's builds is to
simply run `make`. If that does not work, the recommended strategy is to
look at the top of the `Makefile` to see whether any "Makefile knob" has
to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`.
Alternatively, Git also has an `autoconf` setup which allows configuring
builds via `./configure [<option>...]`.
Both of these options are fine if the developer works on Unix or Linux.
But on Windows, we have to jump through hoops to configure a build
(read: we force the user to install a full Git for Windows SDK, which
occupies around two gigabytes (!) on disk and downloads about three
quarters of a gigabyte worth of Git objects).
The build infrastructure for Git is written around being able to run
make, which is not supported natively on Windows.
To help Windows developers a CMake build script is introduced here.
With a working support CMake, developers on Windows need only install
CMake, configure their build, load the generated Visual Studio solution
and immediately start modifying the code and build their own version of
Git. Likewise, developers on other platforms can use the convenient GUI
tools provided by CMake to configure their build.
So let's start building CMake support for Git.
This is only the first step, and to make it easier to review, it only
allows for configuring builds on the platform that is easiest to
configure for: Linux.
The CMake script checks whether the headers are present(eg. libgen.h),
whether the functions are present(eg. memmem), whether the funtions work
properly (eg. snprintf) and generate the required compile definitions
for the platform. The script also searches for the required libraries,
if it fails to find the required libraries the respective executables
won't be built.(eg. If libcurl is not found then git-remote-http won't
be built). This will help building Git easier.
With a CMake script an out of source build of git is possible resulting
in a clean source tree.
Note: this patch asks for the minimum version v3.14 of CMake (which is
not all that old as of time of writing) because that is the first
version to offer a platform-independent way to generate hardlinks as
part of the build. This is needed to generate all those hardlinks for
the built-in commands of Git.
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-12 20:29:19 +02:00
|
|
|
#Creating hardlinks
|
2021-03-28 00:06:22 +01:00
|
|
|
if(NOT SKIP_DASHED_BUILT_INS)
|
Introduce CMake support for configuring Git
At the moment, the recommended way to configure Git's builds is to
simply run `make`. If that does not work, the recommended strategy is to
look at the top of the `Makefile` to see whether any "Makefile knob" has
to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`.
Alternatively, Git also has an `autoconf` setup which allows configuring
builds via `./configure [<option>...]`.
Both of these options are fine if the developer works on Unix or Linux.
But on Windows, we have to jump through hoops to configure a build
(read: we force the user to install a full Git for Windows SDK, which
occupies around two gigabytes (!) on disk and downloads about three
quarters of a gigabyte worth of Git objects).
The build infrastructure for Git is written around being able to run
make, which is not supported natively on Windows.
To help Windows developers a CMake build script is introduced here.
With a working support CMake, developers on Windows need only install
CMake, configure their build, load the generated Visual Studio solution
and immediately start modifying the code and build their own version of
Git. Likewise, developers on other platforms can use the convenient GUI
tools provided by CMake to configure their build.
So let's start building CMake support for Git.
This is only the first step, and to make it easier to review, it only
allows for configuring builds on the platform that is easiest to
configure for: Linux.
The CMake script checks whether the headers are present(eg. libgen.h),
whether the functions are present(eg. memmem), whether the funtions work
properly (eg. snprintf) and generate the required compile definitions
for the platform. The script also searches for the required libraries,
if it fails to find the required libraries the respective executables
won't be built.(eg. If libcurl is not found then git-remote-http won't
be built). This will help building Git easier.
With a CMake script an out of source build of git is possible resulting
in a clean source tree.
Note: this patch asks for the minimum version v3.14 of CMake (which is
not all that old as of time of writing) because that is the first
version to offer a platform-independent way to generate hardlinks as
part of the build. This is needed to generate all those hardlinks for
the built-in commands of Git.
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-12 20:29:19 +02:00
|
|
|
foreach(s ${git_SOURCES} ${git_builtin_extra})
|
|
|
|
|
string(REPLACE "${CMAKE_SOURCE_DIR}/builtin/" "" s ${s})
|
|
|
|
|
string(REPLACE ".c" "" s ${s})
|
2020-06-26 18:11:36 +02:00
|
|
|
file(APPEND ${CMAKE_BINARY_DIR}/CreateLinks.cmake "file(CREATE_LINK git${EXE_EXTENSION} git-${s}${EXE_EXTENSION})\n")
|
|
|
|
|
list(APPEND git_links ${CMAKE_BINARY_DIR}/git-${s}${EXE_EXTENSION})
|
Introduce CMake support for configuring Git
At the moment, the recommended way to configure Git's builds is to
simply run `make`. If that does not work, the recommended strategy is to
look at the top of the `Makefile` to see whether any "Makefile knob" has
to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`.
Alternatively, Git also has an `autoconf` setup which allows configuring
builds via `./configure [<option>...]`.
Both of these options are fine if the developer works on Unix or Linux.
But on Windows, we have to jump through hoops to configure a build
(read: we force the user to install a full Git for Windows SDK, which
occupies around two gigabytes (!) on disk and downloads about three
quarters of a gigabyte worth of Git objects).
The build infrastructure for Git is written around being able to run
make, which is not supported natively on Windows.
To help Windows developers a CMake build script is introduced here.
With a working support CMake, developers on Windows need only install
CMake, configure their build, load the generated Visual Studio solution
and immediately start modifying the code and build their own version of
Git. Likewise, developers on other platforms can use the convenient GUI
tools provided by CMake to configure their build.
So let's start building CMake support for Git.
This is only the first step, and to make it easier to review, it only
allows for configuring builds on the platform that is easiest to
configure for: Linux.
The CMake script checks whether the headers are present(eg. libgen.h),
whether the functions are present(eg. memmem), whether the funtions work
properly (eg. snprintf) and generate the required compile definitions
for the platform. The script also searches for the required libraries,
if it fails to find the required libraries the respective executables
won't be built.(eg. If libcurl is not found then git-remote-http won't
be built). This will help building Git easier.
With a CMake script an out of source build of git is possible resulting
in a clean source tree.
Note: this patch asks for the minimum version v3.14 of CMake (which is
not all that old as of time of writing) because that is the first
version to offer a platform-independent way to generate hardlinks as
part of the build. This is needed to generate all those hardlinks for
the built-in commands of Git.
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-12 20:29:19 +02:00
|
|
|
endforeach()
|
2021-03-28 00:06:22 +01:00
|
|
|
endif()
|
Introduce CMake support for configuring Git
At the moment, the recommended way to configure Git's builds is to
simply run `make`. If that does not work, the recommended strategy is to
look at the top of the `Makefile` to see whether any "Makefile knob" has
to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`.
Alternatively, Git also has an `autoconf` setup which allows configuring
builds via `./configure [<option>...]`.
Both of these options are fine if the developer works on Unix or Linux.
But on Windows, we have to jump through hoops to configure a build
(read: we force the user to install a full Git for Windows SDK, which
occupies around two gigabytes (!) on disk and downloads about three
quarters of a gigabyte worth of Git objects).
The build infrastructure for Git is written around being able to run
make, which is not supported natively on Windows.
To help Windows developers a CMake build script is introduced here.
With a working support CMake, developers on Windows need only install
CMake, configure their build, load the generated Visual Studio solution
and immediately start modifying the code and build their own version of
Git. Likewise, developers on other platforms can use the convenient GUI
tools provided by CMake to configure their build.
So let's start building CMake support for Git.
This is only the first step, and to make it easier to review, it only
allows for configuring builds on the platform that is easiest to
configure for: Linux.
The CMake script checks whether the headers are present(eg. libgen.h),
whether the functions are present(eg. memmem), whether the funtions work
properly (eg. snprintf) and generate the required compile definitions
for the platform. The script also searches for the required libraries,
if it fails to find the required libraries the respective executables
won't be built.(eg. If libcurl is not found then git-remote-http won't
be built). This will help building Git easier.
With a CMake script an out of source build of git is possible resulting
in a clean source tree.
Note: this patch asks for the minimum version v3.14 of CMake (which is
not all that old as of time of writing) because that is the first
version to offer a platform-independent way to generate hardlinks as
part of the build. This is needed to generate all those hardlinks for
the built-in commands of Git.
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-12 20:29:19 +02:00
|
|
|
|
|
|
|
|
if(CURL_FOUND)
|
|
|
|
|
set(remote_exes
|
|
|
|
|
git-remote-https git-remote-ftp git-remote-ftps)
|
|
|
|
|
foreach(s ${remote_exes})
|
2020-06-26 18:11:36 +02:00
|
|
|
file(APPEND ${CMAKE_BINARY_DIR}/CreateLinks.cmake "file(CREATE_LINK git-remote-http${EXE_EXTENSION} ${s}${EXE_EXTENSION})\n")
|
|
|
|
|
list(APPEND git_http_links ${CMAKE_BINARY_DIR}/${s}${EXE_EXTENSION})
|
Introduce CMake support for configuring Git
At the moment, the recommended way to configure Git's builds is to
simply run `make`. If that does not work, the recommended strategy is to
look at the top of the `Makefile` to see whether any "Makefile knob" has
to be turned on/off, e.g. `make NO_OPENSSL=YesPlease`.
Alternatively, Git also has an `autoconf` setup which allows configuring
builds via `./configure [<option>...]`.
Both of these options are fine if the developer works on Unix or Linux.
But on Windows, we have to jump through hoops to configure a build
(read: we force the user to install a full Git for Windows SDK, which
occupies around two gigabytes (!) on disk and downloads about three
quarters of a gigabyte worth of Git objects).
The build infrastructure for Git is written around being able to run
make, which is not supported natively on Windows.
To help Windows developers a CMake build script is introduced here.
With a working support CMake, developers on Windows need only install
CMake, configure their build, load the generated Visual Studio solution
and immediately start modifying the code and build their own version of
Git. Likewise, developers on other platforms can use the convenient GUI
tools provided by CMake to configure their build.
So let's start building CMake support for Git.
This is only the first step, and to make it easier to review, it only
allows for configuring builds on the platform that is easiest to
configure for: Linux.
The CMake script checks whether the headers are present(eg. libgen.h),
whether the functions are present(eg. memmem), whether the funtions work
properly (eg. snprintf) and generate the required compile definitions
for the platform. The script also searches for the required libraries,
if it fails to find the required libraries the respective executables
won't be built.(eg. If libcurl is not found then git-remote-http won't
be built). This will help building Git easier.
With a CMake script an out of source build of git is possible resulting
in a clean source tree.
Note: this patch asks for the minimum version v3.14 of CMake (which is
not all that old as of time of writing) because that is the first
version to offer a platform-independent way to generate hardlinks as
part of the build. This is needed to generate all those hardlinks for
the built-in commands of Git.
Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-12 20:29:19 +02:00
|
|
|
endforeach()
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
add_custom_command(OUTPUT ${git_links} ${git_http_links}
|
|
|
|
|
COMMAND ${CMAKE_COMMAND} -P ${CMAKE_BINARY_DIR}/CreateLinks.cmake
|
|
|
|
|
DEPENDS git git-remote-http)
|
|
|
|
|
add_custom_target(git-links ALL DEPENDS ${git_links} ${git_http_links})
|
2020-06-26 18:11:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
#creating required scripts
|
|
|
|
|
set(SHELL_PATH /bin/sh)
|
|
|
|
|
set(PERL_PATH /usr/bin/perl)
|
|
|
|
|
set(LOCALEDIR ${FALLBACK_RUNTIME_PREFIX}/share/locale)
|
|
|
|
|
set(GITWEBDIR ${FALLBACK_RUNTIME_PREFIX}/share/locale)
|
|
|
|
|
set(INSTLIBDIR ${FALLBACK_RUNTIME_PREFIX}/share/perl5)
|
|
|
|
|
|
|
|
|
|
#shell scripts
|
|
|
|
|
parse_makefile_for_scripts(git_sh_scripts "SCRIPT_SH" ".sh")
|
|
|
|
|
parse_makefile_for_scripts(git_shlib_scripts "SCRIPT_LIB" "")
|
|
|
|
|
set(git_shell_scripts
|
|
|
|
|
${git_sh_scripts} ${git_shlib_scripts} git-instaweb)
|
|
|
|
|
|
|
|
|
|
foreach(script ${git_shell_scripts})
|
|
|
|
|
file(STRINGS ${CMAKE_SOURCE_DIR}/${script}.sh content NEWLINE_CONSUME)
|
|
|
|
|
string(REPLACE "@SHELL_PATH@" "${SHELL_PATH}" content "${content}")
|
|
|
|
|
string(REPLACE "@@DIFF@@" "diff" content "${content}")
|
|
|
|
|
string(REPLACE "@LOCALEDIR@" "${LOCALEDIR}" content "${content}")
|
|
|
|
|
string(REPLACE "@GITWEBDIR@" "${GITWEBDIR}" content "${content}")
|
|
|
|
|
string(REPLACE "@@NO_CURL@@" "" content "${content}")
|
|
|
|
|
string(REPLACE "@@USE_GETTEXT_SCHEME@@" "" content "${content}")
|
|
|
|
|
string(REPLACE "# @@BROKEN_PATH_FIX@@" "" content "${content}")
|
|
|
|
|
string(REPLACE "@@PERL@@" "${PERL_PATH}" content "${content}")
|
|
|
|
|
string(REPLACE "@@SANE_TEXT_GREP@@" "-a" content "${content}")
|
|
|
|
|
string(REPLACE "@@PAGER_ENV@@" "LESS=FRX LV=-c" content "${content}")
|
|
|
|
|
file(WRITE ${CMAKE_BINARY_DIR}/${script} ${content})
|
|
|
|
|
endforeach()
|
|
|
|
|
|
|
|
|
|
#perl scripts
|
|
|
|
|
parse_makefile_for_scripts(git_perl_scripts "SCRIPT_PERL" ".perl")
|
|
|
|
|
|
|
|
|
|
#create perl header
|
|
|
|
|
file(STRINGS ${CMAKE_SOURCE_DIR}/perl/header_templates/fixed_prefix.template.pl perl_header )
|
|
|
|
|
string(REPLACE "@@PATHSEP@@" ":" perl_header "${perl_header}")
|
|
|
|
|
string(REPLACE "@@INSTLIBDIR@@" "${INSTLIBDIR}" perl_header "${perl_header}")
|
|
|
|
|
|
|
|
|
|
foreach(script ${git_perl_scripts})
|
|
|
|
|
file(STRINGS ${CMAKE_SOURCE_DIR}/${script}.perl content NEWLINE_CONSUME)
|
|
|
|
|
string(REPLACE "#!/usr/bin/perl" "#!/usr/bin/perl\n${perl_header}\n" content "${content}")
|
|
|
|
|
string(REPLACE "@@GIT_VERSION@@" "${PROJECT_VERSION}" content "${content}")
|
|
|
|
|
file(WRITE ${CMAKE_BINARY_DIR}/${script} ${content})
|
|
|
|
|
endforeach()
|
|
|
|
|
|
|
|
|
|
#python script
|
|
|
|
|
file(STRINGS ${CMAKE_SOURCE_DIR}/git-p4.py content NEWLINE_CONSUME)
|
|
|
|
|
string(REPLACE "#!/usr/bin/env python" "#!/usr/bin/python" content "${content}")
|
|
|
|
|
file(WRITE ${CMAKE_BINARY_DIR}/git-p4 ${content})
|
|
|
|
|
|
|
|
|
|
#perl modules
|
|
|
|
|
file(GLOB_RECURSE perl_modules "${CMAKE_SOURCE_DIR}/perl/*.pm")
|
|
|
|
|
|
|
|
|
|
foreach(pm ${perl_modules})
|
|
|
|
|
string(REPLACE "${CMAKE_SOURCE_DIR}/perl/" "" file_path ${pm})
|
|
|
|
|
file(STRINGS ${pm} content NEWLINE_CONSUME)
|
|
|
|
|
string(REPLACE "@@LOCALEDIR@@" "${LOCALEDIR}" content "${content}")
|
|
|
|
|
string(REPLACE "@@NO_PERL_CPAN_FALLBACKS@@" "" content "${content}")
|
|
|
|
|
file(WRITE ${CMAKE_BINARY_DIR}/perl/build/lib/${file_path} ${content})
|
|
|
|
|
#test-lib.sh requires perl/build/lib to be the build directory of perl modules
|
|
|
|
|
endforeach()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#templates
|
|
|
|
|
file(GLOB templates "${CMAKE_SOURCE_DIR}/templates/*")
|
|
|
|
|
list(TRANSFORM templates REPLACE "${CMAKE_SOURCE_DIR}/templates/" "")
|
|
|
|
|
list(REMOVE_ITEM templates ".gitignore")
|
|
|
|
|
list(REMOVE_ITEM templates "Makefile")
|
|
|
|
|
list(REMOVE_ITEM templates "blt")# Prevents an error when reconfiguring for in source builds
|
|
|
|
|
|
|
|
|
|
list(REMOVE_ITEM templates "branches--")
|
|
|
|
|
file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/templates/blt/branches) #create branches
|
|
|
|
|
|
|
|
|
|
#templates have @.*@ replacement so use configure_file instead
|
|
|
|
|
foreach(tm ${templates})
|
|
|
|
|
string(REPLACE "--" "/" blt_tm ${tm})
|
|
|
|
|
string(REPLACE "this" "" blt_tm ${blt_tm})# for this--
|
|
|
|
|
configure_file(${CMAKE_SOURCE_DIR}/templates/${tm} ${CMAKE_BINARY_DIR}/templates/blt/${blt_tm} @ONLY)
|
|
|
|
|
endforeach()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#translations
|
|
|
|
|
if(MSGFMT_EXE)
|
|
|
|
|
file(GLOB po_files "${CMAKE_SOURCE_DIR}/po/*.po")
|
|
|
|
|
list(TRANSFORM po_files REPLACE "${CMAKE_SOURCE_DIR}/po/" "")
|
|
|
|
|
list(TRANSFORM po_files REPLACE ".po" "")
|
|
|
|
|
foreach(po ${po_files})
|
|
|
|
|
file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/po/build/locale/${po}/LC_MESSAGES)
|
|
|
|
|
add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/po/build/locale/${po}/LC_MESSAGES/git.mo
|
|
|
|
|
COMMAND ${MSGFMT_EXE} --check --statistics -o ${CMAKE_BINARY_DIR}/po/build/locale/${po}/LC_MESSAGES/git.mo ${CMAKE_SOURCE_DIR}/po/${po}.po)
|
|
|
|
|
list(APPEND po_gen ${CMAKE_BINARY_DIR}/po/build/locale/${po}/LC_MESSAGES/git.mo)
|
|
|
|
|
endforeach()
|
|
|
|
|
add_custom_target(po-gen ALL DEPENDS ${po_gen})
|
|
|
|
|
endif()
|
2020-06-26 18:11:33 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
#to help with the install
|
|
|
|
|
list(TRANSFORM git_shell_scripts PREPEND "${CMAKE_BINARY_DIR}/")
|
|
|
|
|
list(TRANSFORM git_perl_scripts PREPEND "${CMAKE_BINARY_DIR}/")
|
|
|
|
|
|
|
|
|
|
#install
|
2021-03-29 14:41:44 +02:00
|
|
|
foreach(program ${PROGRAMS_BUILT})
|
|
|
|
|
if(program STREQUAL "git" OR program STREQUAL "git-shell")
|
|
|
|
|
install(TARGETS ${program}
|
2020-06-26 18:11:33 +02:00
|
|
|
RUNTIME DESTINATION bin)
|
2021-03-29 14:41:44 +02:00
|
|
|
else()
|
|
|
|
|
install(TARGETS ${program}
|
|
|
|
|
RUNTIME DESTINATION libexec/git-core)
|
|
|
|
|
endif()
|
|
|
|
|
endforeach()
|
|
|
|
|
|
2020-06-26 18:11:33 +02:00
|
|
|
install(PROGRAMS ${CMAKE_BINARY_DIR}/git-cvsserver
|
|
|
|
|
DESTINATION bin)
|
|
|
|
|
|
|
|
|
|
set(bin_links
|
|
|
|
|
git-receive-pack git-upload-archive git-upload-pack)
|
|
|
|
|
|
|
|
|
|
foreach(b ${bin_links})
|
2020-06-26 18:11:36 +02:00
|
|
|
install(CODE "file(CREATE_LINK ${CMAKE_INSTALL_PREFIX}/bin/git${EXE_EXTENSION} ${CMAKE_INSTALL_PREFIX}/bin/${b}${EXE_EXTENSION})")
|
2020-06-26 18:11:33 +02:00
|
|
|
endforeach()
|
|
|
|
|
|
2020-06-26 18:11:36 +02:00
|
|
|
install(CODE "file(CREATE_LINK ${CMAKE_INSTALL_PREFIX}/bin/git${EXE_EXTENSION} ${CMAKE_INSTALL_PREFIX}/libexec/git-core/git${EXE_EXTENSION})")
|
|
|
|
|
install(CODE "file(CREATE_LINK ${CMAKE_INSTALL_PREFIX}/bin/git-shell${EXE_EXTENSION} ${CMAKE_INSTALL_PREFIX}/libexec/git-core/git-shell${EXE_EXTENSION})")
|
2020-06-26 18:11:33 +02:00
|
|
|
|
|
|
|
|
foreach(b ${git_links})
|
|
|
|
|
string(REPLACE "${CMAKE_BINARY_DIR}" "" b ${b})
|
2021-03-28 00:06:23 +01:00
|
|
|
install(CODE "file(CREATE_LINK ${CMAKE_INSTALL_PREFIX}/bin/git${EXE_EXTENSION} ${CMAKE_INSTALL_PREFIX}/libexec/git-core/${b})")
|
2020-06-26 18:11:33 +02:00
|
|
|
endforeach()
|
|
|
|
|
|
|
|
|
|
foreach(b ${git_http_links})
|
|
|
|
|
string(REPLACE "${CMAKE_BINARY_DIR}" "" b ${b})
|
2021-03-28 00:06:23 +01:00
|
|
|
install(CODE "file(CREATE_LINK ${CMAKE_INSTALL_PREFIX}/libexec/git-core/git-remote-http${EXE_EXTENSION} ${CMAKE_INSTALL_PREFIX}/libexec/git-core/${b})")
|
2020-06-26 18:11:33 +02:00
|
|
|
endforeach()
|
|
|
|
|
|
|
|
|
|
install(PROGRAMS ${git_shell_scripts} ${git_perl_scripts} ${CMAKE_BINARY_DIR}/git-p4
|
|
|
|
|
DESTINATION libexec/git-core)
|
|
|
|
|
|
|
|
|
|
install(DIRECTORY ${CMAKE_SOURCE_DIR}/mergetools DESTINATION libexec/git-core)
|
|
|
|
|
install(DIRECTORY ${CMAKE_BINARY_DIR}/perl/build/lib/ DESTINATION share/perl5
|
|
|
|
|
FILES_MATCHING PATTERN "*.pm")
|
|
|
|
|
install(DIRECTORY ${CMAKE_BINARY_DIR}/templates/blt/ DESTINATION share/git-core/templates)
|
|
|
|
|
|
|
|
|
|
if(MSGFMT_EXE)
|
|
|
|
|
install(DIRECTORY ${CMAKE_BINARY_DIR}/po/build/locale DESTINATION share)
|
|
|
|
|
endif()
|
2020-06-26 18:11:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
if(BUILD_TESTING)
|
|
|
|
|
|
|
|
|
|
#tests-helpers
|
|
|
|
|
add_executable(test-fake-ssh ${CMAKE_SOURCE_DIR}/t/helper/test-fake-ssh.c)
|
|
|
|
|
target_link_libraries(test-fake-ssh common-main)
|
|
|
|
|
|
|
|
|
|
#test-tool
|
|
|
|
|
parse_makefile_for_sources(test-tool_SOURCES "TEST_BUILTINS_OBJS")
|
|
|
|
|
|
|
|
|
|
list(TRANSFORM test-tool_SOURCES PREPEND "${CMAKE_SOURCE_DIR}/t/helper/")
|
|
|
|
|
add_executable(test-tool ${CMAKE_SOURCE_DIR}/t/helper/test-tool.c ${test-tool_SOURCES})
|
|
|
|
|
target_link_libraries(test-tool common-main)
|
|
|
|
|
|
drop vcs-svn experiment
The code in vcs-svn was started in 2010 as an attempt to build a
remote-helper for interacting with svn repositories (as opposed to
git-svn). However, we never got as far as shipping a mature remote
helper, and the last substantive commit was e99d012a6bc in 2012.
We do have a git-remote-testsvn, and it is even installed as part of
"make install". But given the name, it seems unlikely to be used by
anybody (you'd have to explicitly "git clone testsvn::$url", and there
have been zero mentions of that on the mailing list since 2013, and even
that includes the phrase "you might need to hack a bit to get it working
properly"[1]).
We also ship contrib/svn-fe, which builds on the vcs-svn work. However,
it does not seem to build out of the box for me, as the link step misses
some required libraries for using libgit.a. Curiously, the original
build breakage bisects for me to eff80a9fd9 (Allow custom "comment
char", 2013-01-16), which seems unrelated. There was an attempt to fix
it in da011cb0e7 (contrib/svn-fe: fix Makefile, 2014-08-28), but on my
system that only switches the error message.
So it seems like the result is not really usable by anybody in practice.
It would be wonderful if somebody wanted to pick up the topic again, and
potentially it's worth carrying around for that reason. But the flip
side is that people doing tree-wide operations have to deal with this
code. And you can see the list with (replace "HEAD" with this commit as
appropriate):
{
echo "--"
git diff-tree --diff-filter=D -r --name-only HEAD^ HEAD
} |
git log --no-merges --oneline e99d012a6bc.. --stdin
which shows 58 times somebody had to deal with the code, generally due
to a compile or test failure, or a tree-wide style fix or API change.
Let's drop it and let anybody who wants to pick it up do so by
resurrecting it from the git history.
As a bonus, this also reduces the size of a stripped installation of Git
from 21MB to 19MB.
[1] https://lore.kernel.org/git/CALkWK0mPHzKfzFKKpZkfAus3YVC9NFYDbFnt+5JQYVKipk3bQQ@mail.gmail.com/
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-13 17:00:17 +02:00
|
|
|
set_target_properties(test-fake-ssh test-tool
|
2020-06-26 18:11:34 +02:00
|
|
|
PROPERTIES RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/t/helper)
|
|
|
|
|
|
2020-06-26 18:11:37 +02:00
|
|
|
if(MSVC)
|
drop vcs-svn experiment
The code in vcs-svn was started in 2010 as an attempt to build a
remote-helper for interacting with svn repositories (as opposed to
git-svn). However, we never got as far as shipping a mature remote
helper, and the last substantive commit was e99d012a6bc in 2012.
We do have a git-remote-testsvn, and it is even installed as part of
"make install". But given the name, it seems unlikely to be used by
anybody (you'd have to explicitly "git clone testsvn::$url", and there
have been zero mentions of that on the mailing list since 2013, and even
that includes the phrase "you might need to hack a bit to get it working
properly"[1]).
We also ship contrib/svn-fe, which builds on the vcs-svn work. However,
it does not seem to build out of the box for me, as the link step misses
some required libraries for using libgit.a. Curiously, the original
build breakage bisects for me to eff80a9fd9 (Allow custom "comment
char", 2013-01-16), which seems unrelated. There was an attempt to fix
it in da011cb0e7 (contrib/svn-fe: fix Makefile, 2014-08-28), but on my
system that only switches the error message.
So it seems like the result is not really usable by anybody in practice.
It would be wonderful if somebody wanted to pick up the topic again, and
potentially it's worth carrying around for that reason. But the flip
side is that people doing tree-wide operations have to deal with this
code. And you can see the list with (replace "HEAD" with this commit as
appropriate):
{
echo "--"
git diff-tree --diff-filter=D -r --name-only HEAD^ HEAD
} |
git log --no-merges --oneline e99d012a6bc.. --stdin
which shows 58 times somebody had to deal with the code, generally due
to a compile or test failure, or a tree-wide style fix or API change.
Let's drop it and let anybody who wants to pick it up do so by
resurrecting it from the git history.
As a bonus, this also reduces the size of a stripped installation of Git
from 21MB to 19MB.
[1] https://lore.kernel.org/git/CALkWK0mPHzKfzFKKpZkfAus3YVC9NFYDbFnt+5JQYVKipk3bQQ@mail.gmail.com/
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-13 17:00:17 +02:00
|
|
|
set_target_properties(test-fake-ssh test-tool
|
2020-06-26 18:11:37 +02:00
|
|
|
PROPERTIES RUNTIME_OUTPUT_DIRECTORY_DEBUG ${CMAKE_BINARY_DIR}/t/helper)
|
drop vcs-svn experiment
The code in vcs-svn was started in 2010 as an attempt to build a
remote-helper for interacting with svn repositories (as opposed to
git-svn). However, we never got as far as shipping a mature remote
helper, and the last substantive commit was e99d012a6bc in 2012.
We do have a git-remote-testsvn, and it is even installed as part of
"make install". But given the name, it seems unlikely to be used by
anybody (you'd have to explicitly "git clone testsvn::$url", and there
have been zero mentions of that on the mailing list since 2013, and even
that includes the phrase "you might need to hack a bit to get it working
properly"[1]).
We also ship contrib/svn-fe, which builds on the vcs-svn work. However,
it does not seem to build out of the box for me, as the link step misses
some required libraries for using libgit.a. Curiously, the original
build breakage bisects for me to eff80a9fd9 (Allow custom "comment
char", 2013-01-16), which seems unrelated. There was an attempt to fix
it in da011cb0e7 (contrib/svn-fe: fix Makefile, 2014-08-28), but on my
system that only switches the error message.
So it seems like the result is not really usable by anybody in practice.
It would be wonderful if somebody wanted to pick up the topic again, and
potentially it's worth carrying around for that reason. But the flip
side is that people doing tree-wide operations have to deal with this
code. And you can see the list with (replace "HEAD" with this commit as
appropriate):
{
echo "--"
git diff-tree --diff-filter=D -r --name-only HEAD^ HEAD
} |
git log --no-merges --oneline e99d012a6bc.. --stdin
which shows 58 times somebody had to deal with the code, generally due
to a compile or test failure, or a tree-wide style fix or API change.
Let's drop it and let anybody who wants to pick it up do so by
resurrecting it from the git history.
As a bonus, this also reduces the size of a stripped installation of Git
from 21MB to 19MB.
[1] https://lore.kernel.org/git/CALkWK0mPHzKfzFKKpZkfAus3YVC9NFYDbFnt+5JQYVKipk3bQQ@mail.gmail.com/
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-13 17:00:17 +02:00
|
|
|
set_target_properties(test-fake-ssh test-tool
|
2020-06-26 18:11:37 +02:00
|
|
|
PROPERTIES RUNTIME_OUTPUT_DIRECTORY_RELEASE ${CMAKE_BINARY_DIR}/t/helper)
|
|
|
|
|
endif()
|
|
|
|
|
|
2020-06-26 18:11:34 +02:00
|
|
|
#wrapper scripts
|
|
|
|
|
set(wrapper_scripts
|
|
|
|
|
git git-upload-pack git-receive-pack git-upload-archive git-shell git-remote-ext)
|
|
|
|
|
|
|
|
|
|
set(wrapper_test_scripts
|
drop vcs-svn experiment
The code in vcs-svn was started in 2010 as an attempt to build a
remote-helper for interacting with svn repositories (as opposed to
git-svn). However, we never got as far as shipping a mature remote
helper, and the last substantive commit was e99d012a6bc in 2012.
We do have a git-remote-testsvn, and it is even installed as part of
"make install". But given the name, it seems unlikely to be used by
anybody (you'd have to explicitly "git clone testsvn::$url", and there
have been zero mentions of that on the mailing list since 2013, and even
that includes the phrase "you might need to hack a bit to get it working
properly"[1]).
We also ship contrib/svn-fe, which builds on the vcs-svn work. However,
it does not seem to build out of the box for me, as the link step misses
some required libraries for using libgit.a. Curiously, the original
build breakage bisects for me to eff80a9fd9 (Allow custom "comment
char", 2013-01-16), which seems unrelated. There was an attempt to fix
it in da011cb0e7 (contrib/svn-fe: fix Makefile, 2014-08-28), but on my
system that only switches the error message.
So it seems like the result is not really usable by anybody in practice.
It would be wonderful if somebody wanted to pick up the topic again, and
potentially it's worth carrying around for that reason. But the flip
side is that people doing tree-wide operations have to deal with this
code. And you can see the list with (replace "HEAD" with this commit as
appropriate):
{
echo "--"
git diff-tree --diff-filter=D -r --name-only HEAD^ HEAD
} |
git log --no-merges --oneline e99d012a6bc.. --stdin
which shows 58 times somebody had to deal with the code, generally due
to a compile or test failure, or a tree-wide style fix or API change.
Let's drop it and let anybody who wants to pick it up do so by
resurrecting it from the git history.
As a bonus, this also reduces the size of a stripped installation of Git
from 21MB to 19MB.
[1] https://lore.kernel.org/git/CALkWK0mPHzKfzFKKpZkfAus3YVC9NFYDbFnt+5JQYVKipk3bQQ@mail.gmail.com/
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-13 17:00:17 +02:00
|
|
|
test-fake-ssh test-tool)
|
2020-06-26 18:11:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
foreach(script ${wrapper_scripts})
|
|
|
|
|
file(STRINGS ${CMAKE_SOURCE_DIR}/wrap-for-bin.sh content NEWLINE_CONSUME)
|
|
|
|
|
string(REPLACE "@@BUILD_DIR@@" "${CMAKE_BINARY_DIR}" content "${content}")
|
2020-06-26 18:11:36 +02:00
|
|
|
string(REPLACE "@@PROG@@" "${script}${EXE_EXTENSION}" content "${content}")
|
2020-06-26 18:11:34 +02:00
|
|
|
file(WRITE ${CMAKE_BINARY_DIR}/bin-wrappers/${script} ${content})
|
|
|
|
|
endforeach()
|
|
|
|
|
|
|
|
|
|
foreach(script ${wrapper_test_scripts})
|
|
|
|
|
file(STRINGS ${CMAKE_SOURCE_DIR}/wrap-for-bin.sh content NEWLINE_CONSUME)
|
|
|
|
|
string(REPLACE "@@BUILD_DIR@@" "${CMAKE_BINARY_DIR}" content "${content}")
|
2020-06-26 18:11:36 +02:00
|
|
|
string(REPLACE "@@PROG@@" "t/helper/${script}${EXE_EXTENSION}" content "${content}")
|
2020-06-26 18:11:34 +02:00
|
|
|
file(WRITE ${CMAKE_BINARY_DIR}/bin-wrappers/${script} ${content})
|
|
|
|
|
endforeach()
|
|
|
|
|
|
|
|
|
|
file(STRINGS ${CMAKE_SOURCE_DIR}/wrap-for-bin.sh content NEWLINE_CONSUME)
|
|
|
|
|
string(REPLACE "@@BUILD_DIR@@" "${CMAKE_BINARY_DIR}" content "${content}")
|
|
|
|
|
string(REPLACE "@@PROG@@" "git-cvsserver" content "${content}")
|
|
|
|
|
file(WRITE ${CMAKE_BINARY_DIR}/bin-wrappers/git-cvsserver ${content})
|
|
|
|
|
|
|
|
|
|
#options for configuring test options
|
|
|
|
|
option(PERL_TESTS "Perform tests that use perl" ON)
|
|
|
|
|
option(PYTHON_TESTS "Perform tests that use python" ON)
|
|
|
|
|
|
|
|
|
|
#GIT-BUILD-OPTIONS
|
|
|
|
|
set(TEST_SHELL_PATH ${SHELL_PATH})
|
|
|
|
|
set(DIFF diff)
|
|
|
|
|
set(PYTHON_PATH /usr/bin/python)
|
|
|
|
|
set(TAR tar)
|
|
|
|
|
set(NO_CURL )
|
|
|
|
|
set(NO_EXPAT )
|
|
|
|
|
set(USE_LIBPCRE2 )
|
|
|
|
|
set(NO_PERL )
|
|
|
|
|
set(NO_PTHREADS )
|
|
|
|
|
set(NO_PYTHON )
|
|
|
|
|
set(PAGER_ENV "LESS=FRX LV=-c")
|
|
|
|
|
set(DC_SHA1 YesPlease)
|
|
|
|
|
set(RUNTIME_PREFIX true)
|
|
|
|
|
set(NO_GETTEXT )
|
|
|
|
|
|
|
|
|
|
if(NOT CURL_FOUND)
|
|
|
|
|
set(NO_CURL 1)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(NOT EXPAT_FOUND)
|
|
|
|
|
set(NO_EXPAT 1)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(NOT Intl_FOUND)
|
|
|
|
|
set(NO_GETTEXT 1)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(NOT PERL_TESTS)
|
|
|
|
|
set(NO_PERL 1)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if(NOT PYTHON_TESTS)
|
|
|
|
|
set(NO_PYTHON 1)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
file(WRITE ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "SHELL_PATH='${SHELL_PATH}'\n")
|
|
|
|
|
file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "TEST_SHELL_PATH='${TEST_SHELL_PATH}'\n")
|
|
|
|
|
file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "PERL_PATH='${PERL_PATH}'\n")
|
|
|
|
|
file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "DIFF='${DIFF}'\n")
|
|
|
|
|
file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "PYTHON_PATH='${PYTHON_PATH}'\n")
|
|
|
|
|
file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "TAR='${TAR}'\n")
|
|
|
|
|
file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "NO_CURL='${NO_CURL}'\n")
|
|
|
|
|
file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "NO_EXPAT='${NO_EXPAT}'\n")
|
|
|
|
|
file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "NO_PERL='${NO_PERL}'\n")
|
|
|
|
|
file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "NO_PTHREADS='${NO_PTHREADS}'\n")
|
|
|
|
|
file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "NO_UNIX_SOCKETS='${NO_UNIX_SOCKETS}'\n")
|
|
|
|
|
file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "PAGER_ENV='${PAGER_ENV}'\n")
|
|
|
|
|
file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "DC_SHA1='${DC_SHA1}'\n")
|
2020-06-26 18:11:36 +02:00
|
|
|
file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "X='${EXE_EXTENSION}'\n")
|
2020-06-26 18:11:34 +02:00
|
|
|
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")
|
2021-05-20 20:28:10 +02:00
|
|
|
file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "SUPPORTS_SIMPLE_IPC='${SUPPORTS_SIMPLE_IPC}'\n")
|
2021-06-06 14:02:52 +02:00
|
|
|
if(USE_VCPKG)
|
2020-09-30 17:26:20 +02:00
|
|
|
file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "PATH=\"$PATH:$TEST_DIRECTORY/../compat/vcbuild/vcpkg/installed/x64-windows/bin\"\n")
|
|
|
|
|
endif()
|
2020-06-26 18:11:34 +02:00
|
|
|
|
2020-06-26 18:11:35 +02:00
|
|
|
#Make the tests work when building out of the source tree
|
|
|
|
|
get_filename_component(CACHE_PATH ${CMAKE_CURRENT_LIST_DIR}/../../CMakeCache.txt ABSOLUTE)
|
|
|
|
|
if(NOT ${CMAKE_BINARY_DIR}/CMakeCache.txt STREQUAL ${CACHE_PATH})
|
|
|
|
|
file(RELATIVE_PATH BUILD_DIR_RELATIVE ${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR}/CMakeCache.txt)
|
|
|
|
|
string(REPLACE "/CMakeCache.txt" "" BUILD_DIR_RELATIVE ${BUILD_DIR_RELATIVE})
|
|
|
|
|
#Setting the build directory in test-lib.sh before running tests
|
|
|
|
|
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"
|
2020-09-30 17:26:19 +02:00
|
|
|
"string(REPLACE \"\${GIT_BUILD_DIR_REPL}\" \"GIT_BUILD_DIR=\\\"$TEST_DIRECTORY/../${BUILD_DIR_RELATIVE}\\\"\" content \"\${content}\")\n"
|
2020-06-26 18:11:35 +02:00
|
|
|
"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/)
|
|
|
|
|
file(COPY ${CMAKE_SOURCE_DIR}/po/is.po DESTINATION ${CMAKE_BINARY_DIR}/po/)
|
|
|
|
|
file(COPY ${CMAKE_SOURCE_DIR}/mergetools/tkdiff DESTINATION ${CMAKE_BINARY_DIR}/mergetools/)
|
|
|
|
|
file(COPY ${CMAKE_SOURCE_DIR}/contrib/completion/git-prompt.sh DESTINATION ${CMAKE_BINARY_DIR}/contrib/completion/)
|
|
|
|
|
file(COPY ${CMAKE_SOURCE_DIR}/contrib/completion/git-completion.bash DESTINATION ${CMAKE_BINARY_DIR}/contrib/completion/)
|
|
|
|
|
endif()
|
|
|
|
|
|
2020-06-26 18:11:34 +02:00
|
|
|
file(GLOB test_scipts "${CMAKE_SOURCE_DIR}/t/t[0-9]*.sh")
|
|
|
|
|
|
|
|
|
|
#test
|
|
|
|
|
foreach(tsh ${test_scipts})
|
|
|
|
|
add_test(NAME ${tsh}
|
|
|
|
|
COMMAND ${SH_EXE} ${tsh}
|
|
|
|
|
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}/t)
|
|
|
|
|
endforeach()
|
|
|
|
|
|
|
|
|
|
endif()#BUILD_TESTING
|