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})
|
git-compat-util: add a test balloon for C99 support
The C99 standard was released in January 1999, now 22 years ago. It
provides a variety of useful features, including variadic arguments for
macros, declarations after statements, designated initializers, and a
wide variety of other useful features, many of which we already use.
We'd like to take advantage of these features, but we want to be
cautious. As far as we know, all major compilers now support C99 or a
later C standard, such as C11 or C17. POSIX has required C99 support as
a requirement for the 2001 revision, so we can safely assume any POSIX
system which we are interested in supporting has C99.
Even MSVC, long a holdout against modern C, now supports both C11 and
C17 with an appropriate update. Moreover, even if people are using an
older version of MSVC on these systems, they will generally need some
implementation of the standard Unix utilities for the testsuite, and GNU
coreutils, the most common option, has required C99 since 2009.
Therefore, we can safely assume that a suitable version of GCC or clang
is available to users even if their version of MSVC is not sufficiently
capable.
Let's add a test balloon to git-compat-util.h to see if anyone is using
an older compiler. We'll add a comment telling people how to enable
this functionality on GCC and Clang, even though modern versions of both
will automatically do the right thing, and ask people still experiencing
a problem to report that to us on the list.
Note that C89 compilers don't provide the __STDC_VERSION__ macro, so we
use a well-known hack of using "- 0". On compilers with this macro, it
doesn't change the value, and on C89 compilers, the macro will be
replaced with nothing, and our value will be 0.
For sparse, we explicitly request the gnu99 style because we've
traditionally taken advantage of some GCC- and clang-specific extensions
when available and we'd like to retain the ability to do that. sparse
also defaults to C89 without it, so things will fail for us if we don't.
Update the cmake configuration to require C11 for MSVC. We do this
because this will make MSVC to use C11, since it does not explicitly
support C99. We do this with a compiler options because setting the
C_STANDARD option does not work in our CI on MSVC and at the moment, we
don't want to require C11 for Unix compilers.
In the Makefile, don't set any compiler flags for the compiler itself,
since on some systems, such as FreeBSD, we actually need C11, and asking
for C99 causes things to fail to compile. The error message should make
it obvious what's going wrong and allow a user to set the appropriate
option when building in the event they're using a Unix compiler that
doesn't support it by default.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-01 02:40:50 +01:00
|
|
|
add_compile_options(/MP /std:c11)
|
2020-06-26 18:11:37 +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
|
|
|
#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()
|
|
|
|
|
|
hook-list.h: add a generated list of hooks, like config-list.h
Make githooks(5) the source of truth for what hooks git supports, and
punt out early on hooks we don't know about in find_hook(). This
ensures that the documentation and the C code's idea about existing
hooks doesn't diverge.
We still have Perl and Python code running its own hooks, but that'll
be addressed by Emily Shaffer's upcoming "git hook run" command.
This resolves a long-standing TODO item in bugreport.c of there being
no centralized listing of hooks, and fixes a bug with the bugreport
listing only knowing about 1/4 of the p4 hooks. It didn't know about
the recent "reference-transaction" hook either.
We could make the find_hook() function die() or BUG() out if the new
known_hook() returned 0, but let's make it return NULL just as it does
when it can't find a hook of a known type. Making it die() is overly
anal, and unlikely to be what we need in catching stupid typos in the
name of some new hook hardcoded in git.git's sources. By making this
be tolerant of unknown hook names, changes in a later series to make
"git hook run" run arbitrary user-configured hook names will be easier
to implement.
I have not been able to directly test the CMake change being made
here. Since 4c2c38e800 (ci: modification of main.yml to use cmake for
vs-build job, 2020-06-26) some of the Windows CI has a hard dependency
on CMake, this change works there, and is to my eyes an obviously
correct use of a pattern established in previous CMake changes,
namely:
- 061c2240b1 (Introduce CMake support for configuring Git,
2020-06-12)
- 709df95b78 (help: move list_config_help to builtin/help,
2020-04-16)
- 976aaedca0 (msvc: add a Makefile target to pre-generate the Visual
Studio solution, 2019-07-29)
The LC_ALL=C is needed because at least in my locale the dash ("-") is
ignored for the purposes of sorting, which results in a different
order. I'm not aware of anything in git that has a hard dependency on
the order, but e.g. the bugreport output would end up using whatever
locale was in effect when git was compiled.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Helped-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-26 21:03:29 +02:00
|
|
|
if(NOT EXISTS ${CMAKE_BINARY_DIR}/hook-list.h)
|
|
|
|
|
message("Generating hook-list.h")
|
|
|
|
|
execute_process(COMMAND ${SH_EXE} ${CMAKE_SOURCE_DIR}/generate-hooklist.sh
|
|
|
|
|
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
|
|
|
|
|
OUTPUT_FILE ${CMAKE_BINARY_DIR}/hook-list.h)
|
|
|
|
|
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
|
|
|
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})
|
|
|
|
|
|
2021-10-07 22:25:00 +02:00
|
|
|
#reftable
|
|
|
|
|
parse_makefile_for_sources(reftable_SOURCES "REFTABLE_OBJS")
|
|
|
|
|
|
|
|
|
|
list(TRANSFORM reftable_SOURCES PREPEND "${CMAKE_SOURCE_DIR}/")
|
|
|
|
|
add_library(reftable STATIC ${reftable_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
|
|
|
|
2021-10-07 22:25:00 +02:00
|
|
|
target_link_libraries(common-main libgit xdiff reftable ${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 "@@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)
|
|
|
|
|
|
2021-10-07 22:25:00 +02:00
|
|
|
#reftable-tests
|
|
|
|
|
parse_makefile_for_sources(test-reftable_SOURCES "REFTABLE_TEST_OBJS")
|
|
|
|
|
list(TRANSFORM test-reftable_SOURCES PREPEND "${CMAKE_SOURCE_DIR}/")
|
|
|
|
|
|
2020-06-26 18:11:34 +02:00
|
|
|
#test-tool
|
|
|
|
|
parse_makefile_for_sources(test-tool_SOURCES "TEST_BUILTINS_OBJS")
|
|
|
|
|
|
|
|
|
|
list(TRANSFORM test-tool_SOURCES PREPEND "${CMAKE_SOURCE_DIR}/t/helper/")
|
2021-10-07 22:25:00 +02:00
|
|
|
add_executable(test-tool ${CMAKE_SOURCE_DIR}/t/helper/test-tool.c ${test-tool_SOURCES} ${test-reftable_SOURCES})
|
2020-06-26 18:11:34 +02:00
|
|
|
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
|