microsoft
/
git
зеркало из https://github.com/microsoft/git.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
git/config.mak.uname

825 строки
25 KiB
Plaintext
Исходник Обычный вид История

Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
# Platform specific Makefile tweaks based on uname detection
msvc: support building Git using MS Visual C++ With this patch, Git can be built using the Microsoft toolchain, via: make MSVC=1 [DEBUG=1] Third party libraries are built from source using the open source "vcpkg" tool set. See https://github.com/Microsoft/vcpkg On a first build, the vcpkg tools and the third party libraries are automatically downloaded and built. DLLs for the third party libraries are copied to the top-level (and t/helper) directory to facilitate debugging. See compat/vcbuild/README. A series of .bat files are invoked by the Makefile to find the location of the installed version of Visual Studio and the associated compiler tools (essentially replicating the environment setup performed by a "Developer Command Prompt"). This should find the most recent VS2015 or VS2017 installation. Output from these scripts are used by the Makefile to define compiler and linker pathnames and -I and -L arguments. The build produces .pdb files for both debug and release builds. Note: This commit was squashed from an organic series of commits developed between 2016 and 2018 in Git for Windows' `master` branch. This combined commit eliminates the obsolete commits related to fetching NuGet packages for third party libraries. It is difficult to use NuGet packages for C/C++ sources because they may be built by earlier versions of the MSVC compiler and have CRT version and linking issues. Additionally, the C/C++ NuGet packages that we were using tended to not be updated concurrently with the sources. And in the case of cURL and OpenSSL, this could expose us to security issues. Helped-by: Yue Lin Ho <b8732003@student.nsysu.edu.tw> Helped-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-25 17:49:39 +03:00
# Define NO_SAFESEH if you need MSVC/Visual Studio to ignore the lack of
# Microsoft's Safe Exception Handling in libraries (such as zlib).
# Typically required for VS2013+/32-bit compilation on Vista+ versions.
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
uname_S := $(shell sh -c 'uname -s 2>/dev/null || echo not')
uname_M := $(shell sh -c 'uname -m 2>/dev/null || echo not')
uname_O := $(shell sh -c 'uname -o 2>/dev/null || echo not')
uname_R := $(shell sh -c 'uname -r 2>/dev/null || echo not')
uname_P := $(shell sh -c 'uname -p 2>/dev/null || echo not')
uname_V := $(shell sh -c 'uname -v 2>/dev/null || echo not')
Makefile: restrict -Wpedantic and -Wno-pedantic-ms-format better 6a8cbc41ba (developer: enable pedantic by default, 2021-09-03) enables pedantic mode in as many compilers as possible to help gather feedback on future tightening, so lets do so. -Wpedantic is missing in some really old gcc 4 versions so lets restrict it to gcc5 and clang4 (it does work in clang3 AFAIK, but it will be unlikely that a developer will use such an old compiler anyway). MinGW gcc is the only one which has -Wno-pedantic-ms-format, and while that is available also in older compilers, the Windows SDK provides gcc10 so lets aim for that. Note that in order to target the flag to only Windows, additional changes were needed in config.mak.uname to propagate the OS detection which also did some minor refactoring, but which is functionaly equivalent. Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-29 06:19:40 +03:00
ifneq ($(findstring MINGW,$(uname_S)),)
uname_S := MINGW
endif
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
ifdef MSVC
# avoid the MingW and Cygwin configuration sections
uname_S := Windows
uname_O := Windows
msvc: support building Git using MS Visual C++ With this patch, Git can be built using the Microsoft toolchain, via: make MSVC=1 [DEBUG=1] Third party libraries are built from source using the open source "vcpkg" tool set. See https://github.com/Microsoft/vcpkg On a first build, the vcpkg tools and the third party libraries are automatically downloaded and built. DLLs for the third party libraries are copied to the top-level (and t/helper) directory to facilitate debugging. See compat/vcbuild/README. A series of .bat files are invoked by the Makefile to find the location of the installed version of Visual Studio and the associated compiler tools (essentially replicating the environment setup performed by a "Developer Command Prompt"). This should find the most recent VS2015 or VS2017 installation. Output from these scripts are used by the Makefile to define compiler and linker pathnames and -I and -L arguments. The build produces .pdb files for both debug and release builds. Note: This commit was squashed from an organic series of commits developed between 2016 and 2018 in Git for Windows' `master` branch. This combined commit eliminates the obsolete commits related to fetching NuGet packages for third party libraries. It is difficult to use NuGet packages for C/C++ sources because they may be built by earlier versions of the MSVC compiler and have CRT version and linking issues. Additionally, the C/C++ NuGet packages that we were using tended to not be updated concurrently with the sources. And in the case of cURL and OpenSSL, this could expose us to security issues. Helped-by: Yue Lin Ho <b8732003@student.nsysu.edu.tw> Helped-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-25 17:49:39 +03:00
# Generate and include makefile variables that point to the
# currently installed set of MSVC command line tools.
compat/vcbuild/MSVC-DEFS-GEN: compat/vcbuild/find_vs_env.bat
@"$<" | tr '\\' / >"$@"
include compat/vcbuild/MSVC-DEFS-GEN
# See if vcpkg and the vcpkg-build versions of the third-party
# libraries that we use are installed. We include the result
# to get $(vcpkg_*) variables defined for the Makefile.
msvc: add a Makefile target to pre-generate the Visual Studio solution The entire idea of generating the VS solution makes only sense if we generate it via Continuous Integration; otherwise potential users would still have to download the entire Git for Windows SDK. If we pre-generate the Visual Studio solution, Git can be built entirely within Visual Studio, and the test scripts can be run in a regular Git for Windows (e.g. the Portable Git flavor, which does not include a full GCC toolchain and therefore weighs only about a tenth of Git for Windows' SDK). So let's just add a target in the Makefile that can be used to generate said solution; The generated files will then be committed so that they can be pushed to a branch ready to check out by Visual Studio users. To make things even more useful, we also generate and commit other files that are required to run the test suite, such as templates and bin-wrappers: with this, developers can run the test suite in a regular Git Bash after building the solution in Visual Studio. Note: for this build target, we do not actually need to initialize the `vcpkg` system, so we don't. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29 23:08:12 +03:00
ifeq (,$(SKIP_VCPKG))
msvc: support building Git using MS Visual C++ With this patch, Git can be built using the Microsoft toolchain, via: make MSVC=1 [DEBUG=1] Third party libraries are built from source using the open source "vcpkg" tool set. See https://github.com/Microsoft/vcpkg On a first build, the vcpkg tools and the third party libraries are automatically downloaded and built. DLLs for the third party libraries are copied to the top-level (and t/helper) directory to facilitate debugging. See compat/vcbuild/README. A series of .bat files are invoked by the Makefile to find the location of the installed version of Visual Studio and the associated compiler tools (essentially replicating the environment setup performed by a "Developer Command Prompt"). This should find the most recent VS2015 or VS2017 installation. Output from these scripts are used by the Makefile to define compiler and linker pathnames and -I and -L arguments. The build produces .pdb files for both debug and release builds. Note: This commit was squashed from an organic series of commits developed between 2016 and 2018 in Git for Windows' `master` branch. This combined commit eliminates the obsolete commits related to fetching NuGet packages for third party libraries. It is difficult to use NuGet packages for C/C++ sources because they may be built by earlier versions of the MSVC compiler and have CRT version and linking issues. Additionally, the C/C++ NuGet packages that we were using tended to not be updated concurrently with the sources. And in the case of cURL and OpenSSL, this could expose us to security issues. Helped-by: Yue Lin Ho <b8732003@student.nsysu.edu.tw> Helped-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-25 17:49:39 +03:00
compat/vcbuild/VCPKG-DEFS: compat/vcbuild/vcpkg_install.bat
@"$<"
include compat/vcbuild/VCPKG-DEFS
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
endif
msvc: add a Makefile target to pre-generate the Visual Studio solution The entire idea of generating the VS solution makes only sense if we generate it via Continuous Integration; otherwise potential users would still have to download the entire Git for Windows SDK. If we pre-generate the Visual Studio solution, Git can be built entirely within Visual Studio, and the test scripts can be run in a regular Git for Windows (e.g. the Portable Git flavor, which does not include a full GCC toolchain and therefore weighs only about a tenth of Git for Windows' SDK). So let's just add a target in the Makefile that can be used to generate said solution; The generated files will then be committed so that they can be pushed to a branch ready to check out by Visual Studio users. To make things even more useful, we also generate and commit other files that are required to run the test suite, such as templates and bin-wrappers: with this, developers can run the test suite in a regular Git Bash after building the solution in Visual Studio. Note: for this build target, we do not actually need to initialize the `vcpkg` system, so we don't. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29 23:08:12 +03:00
endif
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
# We choose to avoid "if .. else if .. else .. endif endif"
# because maintaining the nesting to match is a pain. If
# we had "elif" things would have been much nicer...
ifeq ($(uname_S),OSF1)
# Need this for u_short definitions et al
BASIC_CFLAGS += -D_OSF_SOURCE
SOCKLEN_T = int
NO_STRTOULL = YesPlease
NO_NSEC = YesPlease
endif
ifeq ($(uname_S),Linux)
Portable alloca for Git In the next patch we'll have to use alloca() for performance reasons, but since alloca is non-standardized and is not portable, let's have a trick with compatibility wrappers: 1. at configure time, determine, do we have working alloca() through alloca.h, and define #define HAVE_ALLOCA_H if yes. 2. in code #ifdef HAVE_ALLOCA_H # include <alloca.h> # define xalloca(size) (alloca(size)) # define xalloca_free(p) do {} while(0) #else # define xalloca(size) (xmalloc(size)) # define xalloca_free(p) (free(p)) #endif and use it like func() { p = xalloca(size); ... xalloca_free(p); } This way, for systems, where alloca is available, we'll have optimal on-stack allocations with fast executions. On the other hand, on systems, where alloca is not available, this gracefully fallbacks to xmalloc/free. Both autoconf and config.mak.uname configurations were updated. For autoconf, we are not bothering considering cases, when no alloca.h is available, but alloca() works some other way - its simply alloca.h is available and works or not, everything else is deep legacy. For config.mak.uname, I've tried to make my almost-sure guess for where alloca() is available, but since I only have access to Linux it is the only change I can be sure about myself, with relevant to other changed systems people Cc'ed. NOTE SunOS and Windows had explicit -DHAVE_ALLOCA_H in their configurations. I've changed that to now-common HAVE_ALLOCA_H=YesPlease which should be correct. Cc: Brandon Casey <drafnel@gmail.com> Cc: Marius Storm-Olsen <mstormo@gmail.com> Cc: Johannes Sixt <j6t@kdbg.org> Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de> Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Cc: Gerrit Pape <pape@smarden.org> Cc: Petr Salinger <Petr.Salinger@seznam.cz> Cc: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Thomas Schwinge <thomas@codesourcery.com> (GNU Hurd changes) Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-27 18:22:50 +04:00
HAVE_ALLOCA_H = YesPlease
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
NO_STRLCPY = YesPlease
HAVE_PATHS_H = YesPlease
LIBC_CONTAINS_LIBINTL = YesPlease
HAVE_DEV_TTY = YesPlease
trace: add high resolution timer function to debug performance issues Add a getnanotime() function that returns nanoseconds since 01/01/1970 as unsigned 64-bit integer (i.e. overflows in july 2554). This is easier to work with than e.g. struct timeval or struct timespec. Basing the timer on the epoch allows using the results with other time-related APIs. To simplify adaption to different platforms, split the implementation into a common getnanotime() and a platform-specific highres_nanos() function. The common getnanotime() function handles errors, falling back to gettimeofday() if highres_nanos() isn't implemented or doesn't work. getnanotime() is also responsible for normalizing to the epoch. The offset to the system clock is calculated only once on initialization, i.e. manually setting the system clock has no impact on the timer (except if the fallback gettimeofday() is in use). Git processes are typically short lived, so we don't need to handle clock drift. The highres_nanos() function returns monotonically increasing nanoseconds relative to some arbitrary point in time (e.g. system boot), or 0 on failure. Providing platform-specific implementations should be relatively easy, e.g. adapting to clock_gettime() as defined by the POSIX realtime extensions is seven lines of code. This version includes highres_nanos() implementations for: * Linux: using clock_gettime(CLOCK_MONOTONIC) * Windows: using QueryPerformanceCounter() Todo: * enable clock_gettime() on more platforms * add Mac OSX version, e.g. using mach_absolute_time + mach_timebase_info Signed-off-by: Karsten Blees <blees@dcon.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-12 04:05:42 +04:00
HAVE_CLOCK_GETTIME = YesPlease
configure.ac: check for clock_gettime and CLOCK_MONOTONIC Set or clear Makefile variables HAVE_CLOCK_GETTIME and HAVE_CLOCK_MONOTONIC based upon results of the checks (overriding default values from config.mak.uname). CLOCK_MONOTONIC isn't available on RHEL3, but there are still RHEL3 systems being used in production. Signed-off-by: Reuben Hawkins <reubenhwk@gmail.com> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-08 23:00:56 +03:00
HAVE_CLOCK_MONOTONIC = YesPlease
config.mak.uname: define NEEDS_LIBRT under Linux, for now My Debian wheezy LTS system is still on glibc 2.13; and LTS distros may use older glibc, still, so lets not unnecessarily break things out-of-the-box. We seem to assume Linux is using glibc in our Makefiles anyways, so I don't think this will introduce new breakage for users of alternative libc implementations. Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-11 01:16:44 +03:00
# -lrt is needed for clock_gettime on glibc <= 2.16
NEEDS_LIBRT = YesPlease
core.fsyncmethod: add writeout-only mode This commit introduces the `core.fsyncMethod` configuration knob, which can currently be set to `fsync` or `writeout-only`. The new writeout-only mode attempts to tell the operating system to flush its in-memory page cache to the storage hardware without issuing a CACHE_FLUSH command to the storage controller. Writeout-only fsync is significantly faster than a vanilla fsync on common hardware, since data is written to a disk-side cache rather than all the way to a durable medium. Later changes in this patch series will take advantage of this primitive to implement batching of hardware flushes. When git_fsync is called with FSYNC_WRITEOUT_ONLY, it may fail and the caller is expected to do an ordinary fsync as needed. On Apple platforms, the fsync system call does not issue a CACHE_FLUSH directive to the storage controller. This change updates fsync to do fcntl(F_FULLFSYNC) to make fsync actually durable. We maintain parity with existing behavior on Apple platforms by setting the default value of the new core.fsyncMethod option. Signed-off-by: Neeraj Singh <neerajsi@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-11 01:43:20 +03:00
HAVE_SYNC_FILE_RANGE = YesPlease
strbuf_getwholeline: use getdelim if it is available We spend a lot of time in strbuf_getwholeline in a tight loop reading characters from a stdio handle into a buffer. The libc getdelim() function can do this for us with less overhead. It's in POSIX.1-2008, and was a GNU extension before that. Therefore we can't rely on it, but can fall back to the existing getc loop when it is not available. The HAVE_GETDELIM knob is turned on automatically for Linux, where we have glibc. We don't need to set any new feature-test macros, because we already define _GNU_SOURCE. Other systems that implement getdelim may need to other macros (probably _POSIX_C_SOURCE >= 200809L), but we can address that along with setting the Makefile knob after testing the feature on those systems. Running "git rev-parse refs/heads/does-not-exist" on a repo with an extremely large (1.6GB) packed-refs file went from (best-of-5): real 0m8.601s user 0m8.084s sys 0m0.524s to: real 0m6.768s user 0m6.340s sys 0m0.432s for a wall-clock speedup of 21%. Based on a patch from Rasmus Villemoes <rv@rasmusvillemoes.dk>. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-04-16 12:01:38 +03:00
HAVE_GETDELIM = YesPlease
config.mak.uname: set FREAD_READS_DIRECTORIES for Linux and FreeBSD This variable is added [1] with the assumption that on a sane system, fopen(<dir>, "r") should return NULL. Linux and FreeBSD do not meet this expectation while at least Windows and AIX do. Let's make sure they behave the same way. I only tested one version on Linux (4.7.0 with glibc 2.22) and FreeBSD (11.0) but since GNU/kFreeBSD is fbsd kernel with gnu userspace, I'm pretty sure it shares the same problem. [1] cba22528fa (Add compat/fopen.c which returns NULL on attempt to open directory - 2008-02-08) Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-03 13:16:48 +03:00
FREAD_READS_DIRECTORIES = UnfortunatelyYes
gc --auto: exclude base pack if not enough mem to "repack -ad" pack-objects could be a big memory hog especially on large repos, everybody knows that. The suggestion to stick a .keep file on the giant base pack to avoid this problem is also known for a long time. Recent patches add an option to do just this, but it has to be either configured or activated manually. This patch lets `git gc --auto` activate this mode automatically when it thinks `repack -ad` will use a lot of memory and start affecting the system due to swapping or flushing OS cache. gc --auto decides to do this based on an estimation of pack-objects memory usage, which is quite accurate at least for the heap part, and whether that fits in half of system memory (the assumption here is for desktop environment where there are many other applications running). This mechanism only kicks in if gc.bigBasePackThreshold is not configured. If it is, it is assumed that the user already knows what they want. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-15 18:36:17 +03:00
BASIC_CFLAGS += -DHAVE_SYSINFO
exec_cmd: RUNTIME_PREFIX on some POSIX systems Enable Git to resolve its own binary location using a variety of OS-specific and generic methods, including: - procfs via "/proc/self/exe" (Linux) - _NSGetExecutablePath (Darwin) - KERN_PROC_PATHNAME sysctl on BSDs. - argv0, if absolute (all, including Windows). This is used to enable RUNTIME_PREFIX support for non-Windows systems, notably Linux and Darwin. When configured with RUNTIME_PREFIX, Git will do a best-effort resolution of its executable path and automatically use this as its "exec_path" for relative helper and data lookups, unless explicitly overridden. Small incidental formatting cleanup of "exec_cmd.c". Signed-off-by: Dan Jacques <dnj@google.com> Thanks-to: Robbie Iannucci <iannucci@google.com> Thanks-to: Junio C Hamano <gitster@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-10 18:05:44 +03:00
PROCFS_EXECUTABLE_PATH = /proc/self/exe
tr2: log parent process name It can be useful to tell who invoked Git - was it invoked manually by a user via CLI or script? By an IDE? In some cases - like 'repo' tool - we can influence the source code and set the GIT_TRACE2_PARENT_SID environment variable from the caller process. In 'repo''s case, that parent SID is manipulated to include the string "repo", which means we can positively identify when Git was invoked by 'repo' tool. However, identifying parents that way requires both that we know which tools invoke Git and that we have the ability to modify the source code of those tools. It cannot scale to keep up with the various IDEs and wrappers which use Git, most of which we don't know about. Learning which tools and wrappers invoke Git, and how, would give us insight to decide where to improve Git's usability and performance. Unfortunately, there's no cross-platform reliable way to gather the name of the parent process. If procfs is present, we can use that; otherwise we will need to discover the name another way. However, the process ID should be sufficient to look up the process name on most platforms, so that code may be shareable. Git for Windows gathers similar information and logs it as a "data_json" event. However, since "data_json" has a variable format, it is difficult to parse effectively in some languages; instead, let's pursue a dedicated "cmd_ancestry" event to record information about the ancestry of the current process and a consistent, parseable way. Git for Windows also gathers information about more than one generation of parent. In Linux further ancestry info can be gathered with procfs, but it's unwieldy to do so. In the interest of later moving Git for Windows ancestry logging to the 'cmd_ancestry' event, and in the interest of later adding more ancestry to the Linux implementation - or of adding this functionality to other platforms which have an easier time walking the process tree - let's make 'cmd_ancestry' accept an array of parentage. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-22 04:27:07 +03:00
HAVE_PLATFORM_PROCINFO = YesPlease
COMPAT_OBJS += compat/linux/procinfo.o
build: centos/RHEL 7 ships with an older gcc and zlib GCC 4.8.5 is the default system compiler on centos7/RHEL7. This version requires -std=c99 to enable c99 support. zlib 1.2.7 on centos7/rhel7 lacks uncompress2(). Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-16 05:05:20 +03:00
# centos7/rhel7 provides gcc 4.8.5 and zlib 1.2.7.
ifneq ($(findstring .el7.,$(uname_R)),)
BASIC_CFLAGS += -std=c99
endif
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
endif
ifeq ($(uname_S),GNU/kFreeBSD)
Portable alloca for Git In the next patch we'll have to use alloca() for performance reasons, but since alloca is non-standardized and is not portable, let's have a trick with compatibility wrappers: 1. at configure time, determine, do we have working alloca() through alloca.h, and define #define HAVE_ALLOCA_H if yes. 2. in code #ifdef HAVE_ALLOCA_H # include <alloca.h> # define xalloca(size) (alloca(size)) # define xalloca_free(p) do {} while(0) #else # define xalloca(size) (xmalloc(size)) # define xalloca_free(p) (free(p)) #endif and use it like func() { p = xalloca(size); ... xalloca_free(p); } This way, for systems, where alloca is available, we'll have optimal on-stack allocations with fast executions. On the other hand, on systems, where alloca is not available, this gracefully fallbacks to xmalloc/free. Both autoconf and config.mak.uname configurations were updated. For autoconf, we are not bothering considering cases, when no alloca.h is available, but alloca() works some other way - its simply alloca.h is available and works or not, everything else is deep legacy. For config.mak.uname, I've tried to make my almost-sure guess for where alloca() is available, but since I only have access to Linux it is the only change I can be sure about myself, with relevant to other changed systems people Cc'ed. NOTE SunOS and Windows had explicit -DHAVE_ALLOCA_H in their configurations. I've changed that to now-common HAVE_ALLOCA_H=YesPlease which should be correct. Cc: Brandon Casey <drafnel@gmail.com> Cc: Marius Storm-Olsen <mstormo@gmail.com> Cc: Johannes Sixt <j6t@kdbg.org> Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de> Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Cc: Gerrit Pape <pape@smarden.org> Cc: Petr Salinger <Petr.Salinger@seznam.cz> Cc: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Thomas Schwinge <thomas@codesourcery.com> (GNU Hurd changes) Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-27 18:22:50 +04:00
HAVE_ALLOCA_H = YesPlease
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
NO_STRLCPY = YesPlease
HAVE_PATHS_H = YesPlease
DIR_HAS_BSD_GROUP_SEMANTICS = YesPlease
LIBC_CONTAINS_LIBINTL = YesPlease
config.mak.uname: set FREAD_READS_DIRECTORIES for Linux and FreeBSD This variable is added [1] with the assumption that on a sane system, fopen(<dir>, "r") should return NULL. Linux and FreeBSD do not meet this expectation while at least Windows and AIX do. Let's make sure they behave the same way. I only tested one version on Linux (4.7.0 with glibc 2.22) and FreeBSD (11.0) but since GNU/kFreeBSD is fbsd kernel with gnu userspace, I'm pretty sure it shares the same problem. [1] cba22528fa (Add compat/fopen.c which returns NULL on attempt to open directory - 2008-02-08) Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-03 13:16:48 +03:00
FREAD_READS_DIRECTORIES = UnfortunatelyYes
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
endif
ifeq ($(uname_S),UnixWare)
CC = cc
NEEDS_SOCKET = YesPlease
NEEDS_NSL = YesPlease
NEEDS_SSL_WITH_CRYPTO = YesPlease
NEEDS_LIBICONV = YesPlease
SHELL_PATH = /usr/local/bin/bash
NO_IPV6 = YesPlease
NO_HSTRERROR = YesPlease
BASIC_CFLAGS += -Kthread
BASIC_CFLAGS += -I/usr/local/include
BASIC_LDFLAGS += -L/usr/local/lib
INSTALL = ginstall
TAR = gtar
NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
endif
ifeq ($(uname_S),SCO_SV)
ifeq ($(uname_R),3.2)
CFLAGS = -O2
endif
ifeq ($(uname_R),5)
CC = cc
BASIC_CFLAGS += -Kthread
endif
NEEDS_SOCKET = YesPlease
NEEDS_NSL = YesPlease
NEEDS_SSL_WITH_CRYPTO = YesPlease
NEEDS_LIBICONV = YesPlease
SHELL_PATH = /usr/bin/bash
NO_IPV6 = YesPlease
NO_HSTRERROR = YesPlease
BASIC_CFLAGS += -I/usr/local/include
BASIC_LDFLAGS += -L/usr/local/lib
NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
INSTALL = ginstall
TAR = gtar
endif
ifeq ($(uname_S),Darwin)
NEEDS_CRYPTO_WITH_SSL = YesPlease
NEEDS_SSL_WITH_CRYPTO = YesPlease
NEEDS_LIBICONV = YesPlease
config.mak.uname: add hint on uname_R for MacOS X I always have to scratch my head every time I see this cryptic pattern "[15678]\."; leave a short note to remind the maintainer and the reviewers. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-15 21:02:46 +04:00
# Note: $(uname_R) gives us the underlying Darwin version.
# - MacOS 10.0.* and MacOS 10.1.0 = Darwin 1.*
# - MacOS 10.x.* = Darwin (x+4).* for (1 <= x)
# i.e. "begins with [15678] and a dot" means "10.4.* or older".
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
ifeq ($(shell expr "$(uname_R)" : '[15678]\.'),2)
OLD_ICONV = UnfortunatelyYes
config.mak.uname: set NO_APPLE_COMMON_CRYPTO on older systems Older MacOS systems prior to 10.5 do not have the CommonCrypto support Git uses so set NO_APPLE_COMMON_CRYPTO on those systems. Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-15 11:46:11 +04:00
NO_APPLE_COMMON_CRYPTO = YesPlease
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
endif
ifeq ($(shell expr "$(uname_R)" : '[15]\.'),2)
NO_STRLCPY = YesPlease
endif
config.mak.uname: Darwin: define HAVE_GETDELIM for modern OS X releases On Mac OS X, getdelim() first became available with Xcode 4.1[1], which was released the same day as OS X 10.7 "Lion", so assume getdelim() availability from 10.7 onward. (As of this writing, OS X is at 10.10 "Yosemite".) According to Wikipedia[2], 4.1 was also available for download by paying developers on OS X 10.6 "Snow Leopard", so it's possible that some 10.6 machines may have getdelim(). However, as strbuf's use of getdelim() is purely an optimization, let's be conservative and assume 10.6 and earlier lack getdelim(). [1]: Or, possibly with Xcode 4.0, but that version is no longer available for download, or not available to non-paying developers, so testing is not possible. [2]: http://en.wikipedia.org/wiki/Xcode Helped-by: Jeff King <peff@peff.net> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-03 00:15:43 +03:00
ifeq ($(shell test "`expr "$(uname_R)" : '\([0-9][0-9]*\)\.'`" -ge 11 && echo 1),1)
HAVE_GETDELIM = YesPlease
endif
config.mak.uname: enable OPEN_RETURNS_EINTR for macOS Big Sur We've had mixed reports on whether the latest release of macOS needs this Makefile knob set. In most reported cases, there's antivirus software running (which one might imagine could cause an open() call to be delayed). However, one of the (off-list) reports I've gotten indicated that it happened on an otherwise clean install of Big Sur. Since the symptom is so bad (checkout randomly fails to write several fails when the progress meter kicks in), and since the workaround is so lightweight (if we don't see EINTR, it's just an extra conditional check), let's just turn it on by default. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-01 12:29:47 +03:00
ifeq ($(shell test "`expr "$(uname_R)" : '\([0-9][0-9]*\)\.'`" -ge 20 && echo 1),1)
OPEN_RETURNS_EINTR = UnfortunatelyYes
endif
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
NO_MEMMEM = YesPlease
USE_ST_TIMESPEC = YesPlease
HAVE_DEV_TTY = YesPlease
COMPAT_OBJS += compat/precompose_utf8.o
BASIC_CFLAGS += -DPRECOMPOSE_UNICODE
read-cache: optionally disallow HFS+ .git variants The point of disallowing ".git" in the index is that we would never want to accidentally overwrite files in the repository directory. But this means we need to respect the filesystem's idea of when two paths are equal. The prior commit added a helper to make such a comparison for HFS+; let's use it in verify_path. We make this check optional for two reasons: 1. It restricts the set of allowable filenames, which is unnecessary for people who are not on HFS+. In practice this probably doesn't matter, though, as the restricted names are rather obscure and almost certainly would never come up in practice. 2. It has a minor performance penalty for every path we insert into the index. This patch ties the check to the core.protectHFS config option. Though this is expected to be most useful on OS X, we allow it to be set everywhere, as HFS+ may be mounted on other platforms. The variable does default to on for OS X, though. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-16 02:15:20 +03:00
BASIC_CFLAGS += -DPROTECT_HFS_DEFAULT=1
configure: support HAVE_BSD_SYSCTL option On BSD-compatible systems some information such as the number of available CPUs may only be available via the sysctl function. Add support for a HAVE_BSD_SYSCTL option complete with autoconf support and include the sys/syctl.h header when the option is enabled to make the sysctl function available. Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-08 10:14:36 +03:00
HAVE_BSD_SYSCTL = YesPlease
config.mak.uname: set FREAD_READS_DIRECTORIES for Darwin, too Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-10 07:44:33 +03:00
FREAD_READS_DIRECTORIES = UnfortunatelyYes
exec_cmd: RUNTIME_PREFIX on some POSIX systems Enable Git to resolve its own binary location using a variety of OS-specific and generic methods, including: - procfs via "/proc/self/exe" (Linux) - _NSGetExecutablePath (Darwin) - KERN_PROC_PATHNAME sysctl on BSDs. - argv0, if absolute (all, including Windows). This is used to enable RUNTIME_PREFIX support for non-Windows systems, notably Linux and Darwin. When configured with RUNTIME_PREFIX, Git will do a best-effort resolution of its executable path and automatically use this as its "exec_path" for relative helper and data lookups, unless explicitly overridden. Small incidental formatting cleanup of "exec_cmd.c". Signed-off-by: Dan Jacques <dnj@google.com> Thanks-to: Robbie Iannucci <iannucci@google.com> Thanks-to: Junio C Hamano <gitster@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-10 18:05:44 +03:00
HAVE_NS_GET_EXECUTABLE_PATH = YesPlease
wrapper: add a helper to generate numbers from a CSPRNG There are many situations in which having access to a cryptographically secure pseudorandom number generator (CSPRNG) is helpful. In the future, we'll encounter one of these when dealing with temporary files. To make this possible, let's add a function which reads from a system CSPRNG and returns some bytes. We know that all systems will have such an interface. A CSPRNG is required for a secure TLS or SSH implementation and a Git implementation which provided neither would be of little practical use. In addition, POSIX is set to standardize getentropy(2) in the next version, so in the (potentially distant) future we can rely on that. For systems which lack one of the other interfaces, we provide the ability to use OpenSSL's CSPRNG. OpenSSL is highly portable and functions on practically every known OS, and we know it will have access to some source of cryptographically secure randomness. We also provide support for the arc4random in libbsd for folks who would prefer to use that. Because this is a security sensitive interface, we take some precautions. We either succeed by filling the buffer completely as we requested, or we fail. We don't return partial data because the caller will almost never find that to be a useful behavior. Specify a makefile knob which users can use to specify one or more suitable CSPRNGs, and turn the multiple string options into a set of defines, since we cannot match on strings in the preprocessor. We allow multiple options to make the job of handling this in autoconf easier. The order of options is important here. On systems with arc4random, which is most of the BSDs, we use that, since, except on MirBSD and macOS, it uses ChaCha20, which is extremely fast, and sits entirely in userspace, avoiding a system call. We then prefer getrandom over getentropy, because the former has been available longer on Linux, and then OpenSSL. Finally, if none of those are available, we use /dev/urandom, because most Unix-like operating systems provide that API. We prefer options that don't involve device files when possible because those work in some restricted environments where device files may not be available. Set the configuration variables appropriately for Linux and the BSDs, including macOS, as well as Windows and NonStop. We specifically only consider versions which receive publicly available security support here. For the same reason, we don't specify getrandom(2) on Linux, because CentOS 7 doesn't support it in glibc (although its kernel does) and we don't want to resort to making syscalls. Finally, add a test helper to allow this to be tested by hand and in tests. We don't add any tests, since invoking the CSPRNG is not likely to produce interesting, reproducible results. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-18 00:56:16 +03:00
CSPRNG_METHOD = arc4random
macOS/brew: let the build find gettext headers/libraries/msgfmt Apparently a recent Homebrew update now installs `gettext` into the subdirectory /usr/local/opt/gettext/[lib/include]. Sometimes the ci job succeeds: brew link --force gettext Linking /usr/local/Cellar/gettext/0.20.1... 179 symlinks created And sometimes installing the package "gettext" with force-link fails: brew link --force gettext Warning: Refusing to link macOS provided/shadowed software: gettext If you need to have gettext first in your PATH run: echo 'export PATH="/usr/local/opt/gettext/bin:$PATH"' >> ~/.bash_profile (And the is not the final word either, since macOS itself says: The default interactive shell is now zsh.) Anyway, The latter requires CFLAGS to include /usr/local/opt/gettext/include and LDFLAGS to include /usr/local/opt/gettext/lib. Likewise, the `msgfmt` tool is no longer in the `PATH`. While it is unclear which change is responsible for this breakage (that most notably only occurs on CI build agents that updated very recently), https://github.com/Homebrew/homebrew-core/pull/53489 has fixed it. Nevertheless, let's work around this issue, as there are still quite a few build agents out there that need some help in this regard: we explicitly do not call `brew update` in our CI/PR builds anymore. Helped-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-26 23:09:32 +03:00
# Workaround for `gettext` being keg-only and not even being linked via
# `brew link --force gettext`, should be obsolete as of
# https://github.com/Homebrew/homebrew-core/pull/53489
ifeq ($(shell test -d /usr/local/opt/gettext/ && echo y),y)
BASIC_CFLAGS += -I/usr/local/include -I/usr/local/opt/gettext/include
BASIC_LDFLAGS += -L/usr/local/lib -L/usr/local/opt/gettext/lib
ifeq ($(shell test -x /usr/local/opt/gettext/bin/msgfmt && echo y),y)
MSGFMT = /usr/local/opt/gettext/bin/msgfmt
endif
endif
compat/fsmonitor/fsm-listen-darwin: stub in backend for Darwin Stub in empty implementation of fsmonitor--daemon backend for Darwin (aka MacOS). Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-25 21:02:52 +03:00
# The builtin FSMonitor on MacOS builds upon Simple-IPC. Both require
# Unix domain sockets and PThreads.
ifndef NO_PTHREADS
ifndef NO_UNIX_SOCKETS
FSMONITOR_DAEMON_BACKEND = darwin
endif
endif
BASIC_LDFLAGS += -framework CoreServices
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
endif
ifeq ($(uname_S),SunOS)
NEEDS_SOCKET = YesPlease
NEEDS_NSL = YesPlease
SHELL_PATH = /bin/bash
SANE_TOOL_PATH = /usr/xpg6/bin:/usr/xpg4/bin
Portable alloca for Git In the next patch we'll have to use alloca() for performance reasons, but since alloca is non-standardized and is not portable, let's have a trick with compatibility wrappers: 1. at configure time, determine, do we have working alloca() through alloca.h, and define #define HAVE_ALLOCA_H if yes. 2. in code #ifdef HAVE_ALLOCA_H # include <alloca.h> # define xalloca(size) (alloca(size)) # define xalloca_free(p) do {} while(0) #else # define xalloca(size) (xmalloc(size)) # define xalloca_free(p) (free(p)) #endif and use it like func() { p = xalloca(size); ... xalloca_free(p); } This way, for systems, where alloca is available, we'll have optimal on-stack allocations with fast executions. On the other hand, on systems, where alloca is not available, this gracefully fallbacks to xmalloc/free. Both autoconf and config.mak.uname configurations were updated. For autoconf, we are not bothering considering cases, when no alloca.h is available, but alloca() works some other way - its simply alloca.h is available and works or not, everything else is deep legacy. For config.mak.uname, I've tried to make my almost-sure guess for where alloca() is available, but since I only have access to Linux it is the only change I can be sure about myself, with relevant to other changed systems people Cc'ed. NOTE SunOS and Windows had explicit -DHAVE_ALLOCA_H in their configurations. I've changed that to now-common HAVE_ALLOCA_H=YesPlease which should be correct. Cc: Brandon Casey <drafnel@gmail.com> Cc: Marius Storm-Olsen <mstormo@gmail.com> Cc: Johannes Sixt <j6t@kdbg.org> Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de> Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Cc: Gerrit Pape <pape@smarden.org> Cc: Petr Salinger <Petr.Salinger@seznam.cz> Cc: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Thomas Schwinge <thomas@codesourcery.com> (GNU Hurd changes) Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-27 18:22:50 +04:00
HAVE_ALLOCA_H = YesPlease
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
NO_MKDTEMP = YesPlease
NO_REGEX = YesPlease
NO_MSGFMT_EXTENDED_OPTIONS = YesPlease
HAVE_DEV_TTY = YesPlease
ifeq ($(uname_R),5.6)
SOCKLEN_T = int
NO_HSTRERROR = YesPlease
NO_IPV6 = YesPlease
NO_SOCKADDR_STORAGE = YesPlease
NO_UNSETENV = YesPlease
NO_SETENV = YesPlease
NO_STRLCPY = YesPlease
NO_STRTOUMAX = YesPlease
GIT_TEST_CMP = cmp
endif
ifeq ($(uname_R),5.7)
NEEDS_RESOLV = YesPlease
NO_IPV6 = YesPlease
NO_SOCKADDR_STORAGE = YesPlease
NO_UNSETENV = YesPlease
NO_SETENV = YesPlease
NO_STRLCPY = YesPlease
NO_STRTOUMAX = YesPlease
GIT_TEST_CMP = cmp
endif
ifeq ($(uname_R),5.8)
NO_UNSETENV = YesPlease
NO_SETENV = YesPlease
NO_STRTOUMAX = YesPlease
GIT_TEST_CMP = cmp
endif
ifeq ($(uname_R),5.9)
NO_UNSETENV = YesPlease
NO_SETENV = YesPlease
NO_STRTOUMAX = YesPlease
GIT_TEST_CMP = cmp
endif
INSTALL = /usr/ucb/install
TAR = gtar
Portable alloca for Git In the next patch we'll have to use alloca() for performance reasons, but since alloca is non-standardized and is not portable, let's have a trick with compatibility wrappers: 1. at configure time, determine, do we have working alloca() through alloca.h, and define #define HAVE_ALLOCA_H if yes. 2. in code #ifdef HAVE_ALLOCA_H # include <alloca.h> # define xalloca(size) (alloca(size)) # define xalloca_free(p) do {} while(0) #else # define xalloca(size) (xmalloc(size)) # define xalloca_free(p) (free(p)) #endif and use it like func() { p = xalloca(size); ... xalloca_free(p); } This way, for systems, where alloca is available, we'll have optimal on-stack allocations with fast executions. On the other hand, on systems, where alloca is not available, this gracefully fallbacks to xmalloc/free. Both autoconf and config.mak.uname configurations were updated. For autoconf, we are not bothering considering cases, when no alloca.h is available, but alloca() works some other way - its simply alloca.h is available and works or not, everything else is deep legacy. For config.mak.uname, I've tried to make my almost-sure guess for where alloca() is available, but since I only have access to Linux it is the only change I can be sure about myself, with relevant to other changed systems people Cc'ed. NOTE SunOS and Windows had explicit -DHAVE_ALLOCA_H in their configurations. I've changed that to now-common HAVE_ALLOCA_H=YesPlease which should be correct. Cc: Brandon Casey <drafnel@gmail.com> Cc: Marius Storm-Olsen <mstormo@gmail.com> Cc: Johannes Sixt <j6t@kdbg.org> Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de> Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Cc: Gerrit Pape <pape@smarden.org> Cc: Petr Salinger <Petr.Salinger@seznam.cz> Cc: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Thomas Schwinge <thomas@codesourcery.com> (GNU Hurd changes) Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-27 18:22:50 +04:00
BASIC_CFLAGS += -D__EXTENSIONS__ -D__sun__
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
endif
ifeq ($(uname_O),Cygwin)
ifeq ($(shell expr "$(uname_R)" : '1\.[1-6]\.'),4)
NO_D_TYPE_IN_DIRENT = YesPlease
NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
NO_SYMLINK_HEAD = YesPlease
NO_IPV6 = YesPlease
OLD_ICONV = UnfortunatelyYes
Cygwin 1.7 supports mmap git has shipped for years with MMAP enabled in the stock distribution, there are no reports of problems / failures on the list relating to this. Leave the default as-is on v1.5 due to lack of knowlege of this working on earlier Cygwin. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-20 03:08:30 +04:00
# There are conflicting reports about this.
# On some boxes NO_MMAP is needed, and not so elsewhere.
# Try commenting this out if you suspect MMAP is more efficient
NO_MMAP = YesPlease
Cygwin 1.7 needs compat/regex Cygwin v1.7 uses the regex library from newlib which does not pass git's tests, so don't use it. This fixes failures in t4018 and t4034. Continue to use the platform supplied regex library for earlier versions. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-20 03:08:28 +04:00
else
NO_REGEX = UnfortunatelyYes
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
endif
Portable alloca for Git In the next patch we'll have to use alloca() for performance reasons, but since alloca is non-standardized and is not portable, let's have a trick with compatibility wrappers: 1. at configure time, determine, do we have working alloca() through alloca.h, and define #define HAVE_ALLOCA_H if yes. 2. in code #ifdef HAVE_ALLOCA_H # include <alloca.h> # define xalloca(size) (alloca(size)) # define xalloca_free(p) do {} while(0) #else # define xalloca(size) (xmalloc(size)) # define xalloca_free(p) (free(p)) #endif and use it like func() { p = xalloca(size); ... xalloca_free(p); } This way, for systems, where alloca is available, we'll have optimal on-stack allocations with fast executions. On the other hand, on systems, where alloca is not available, this gracefully fallbacks to xmalloc/free. Both autoconf and config.mak.uname configurations were updated. For autoconf, we are not bothering considering cases, when no alloca.h is available, but alloca() works some other way - its simply alloca.h is available and works or not, everything else is deep legacy. For config.mak.uname, I've tried to make my almost-sure guess for where alloca() is available, but since I only have access to Linux it is the only change I can be sure about myself, with relevant to other changed systems people Cc'ed. NOTE SunOS and Windows had explicit -DHAVE_ALLOCA_H in their configurations. I've changed that to now-common HAVE_ALLOCA_H=YesPlease which should be correct. Cc: Brandon Casey <drafnel@gmail.com> Cc: Marius Storm-Olsen <mstormo@gmail.com> Cc: Johannes Sixt <j6t@kdbg.org> Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de> Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Cc: Gerrit Pape <pape@smarden.org> Cc: Petr Salinger <Petr.Salinger@seznam.cz> Cc: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Thomas Schwinge <thomas@codesourcery.com> (GNU Hurd changes) Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-27 18:22:50 +04:00
HAVE_ALLOCA_H = YesPlease
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
NEEDS_LIBICONV = YesPlease
NO_FAST_WORKING_DIRECTORY = UnfortunatelyYes
NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
X = .exe
UNRELIABLE_FSTAT = UnfortunatelyYes
config.mak.uname: Cygwin needs OBJECT_CREATION_USES_RENAMES This is necessary to use Git on Windows shared directories, and is already enabled for the MinGW and plain Windows builds. This problem was reported on the Cygwin mailing list at https://cygwin.com/ml/cygwin/2015-08/msg00102.html (amongst others) and is being applied as a manual patch to the Cygwin builds until the patch is taken here. Reported-by: Peter Rosin <peda@lysator.liu.se> Signed-off-by: Adam Dinwoodie <adam@dinwoodie.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-07 23:30:28 +03:00
OBJECT_CREATION_USES_RENAMES = UnfortunatelyNeedsTo
packed_ref_cache: keep the `packed-refs` file mmapped if possible Keep a copy of the `packed-refs` file contents in memory for as long as a `packed_ref_cache` object is in use: * If the system allows it, keep the `packed-refs` file mmapped. * If not (either because the system doesn't support `mmap()` at all, or because a file that is currently mmapped cannot be replaced via `rename()`), then make a copy of the file's contents in heap-allocated space, and keep that around instead. We base the choice of behavior on a new build-time switch, `MMAP_PREVENTS_DELETE`. By default, this switch is set for Windows variants. After this commit, `MMAP_NONE` and `MMAP_TEMPORARY` are still handled identically. But the next commit will introduce a difference. This whole change is still pointless, because we only read the `packed-refs` file contents immediately after instantiating the `packed_ref_cache`. But that will soon change. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-25 11:00:10 +03:00
MMAP_PREVENTS_DELETE = UnfortunatelyYes
git clone <url> C:\cygwin\home\USER\repo' is working (again) A regression for cygwin users was introduced with commit 05b458c, "real_path: resolve symlinks by hand". In the the commit message we read: The current implementation of real_path uses chdir() in order to resolve symlinks. Unfortunately this isn't thread-safe as chdir() affects a process as a whole... The old (and non-thread-save) OS calls chdir()/pwd() had been replaced by a string operation. The cygwin layer "knows" that "C:\cygwin" is an absolute path, but the new string operation does not. "git clone <url> C:\cygwin\home\USER\repo" fails like this: fatal: Invalid path '/home/USER/repo/C:\cygwin\home\USER\repo' The solution is to implement has_dos_drive_prefix(), skip_dos_drive_prefix() is_dir_sep(), offset_1st_component() and convert_slashes() for cygwin in the same way as it is done in 'Git for Windows' in compat/mingw.[ch] Extract the needed code into compat/win32/path-utils.[ch] and use it for cygwin as well. Reported-by: Steven Penny <svnpenn@gmail.com> Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-15 07:33:30 +03:00
COMPAT_OBJS += compat/win32/path-utils.o
config.mak.uname: set FREAD_READS_DIRECTORIES for cygwin Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-21 21:43:17 +03:00
FREAD_READS_DIRECTORIES = UnfortunatelyYes
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
endif
ifeq ($(uname_S),FreeBSD)
NEEDS_LIBICONV = YesPlease
config.mak.uname: resolve FreeBSD iconv-related compilation warning OLD_ICONV has long been needed by FreeBSD so config.mak.uname defines it unconditionally. However, recent versions do not need it, and its presence results in compilation warnings. Resolve this issue by defining OLD_ICONV only for older FreeBSD versions. Specifically, revision r281550[1], which is part of FreeBSD 11, removed the need for OLD_ICONV, and r282275[2] back-ported that change to 10.2. Versions prior to 10.2 do need it. [1] https://github.com/freebsd/freebsd/commit/b0813ee288f64f677a2cebf7815754b027a8215b [2] https://github.com/freebsd/freebsd/commit/b709ec868adb5170d09bc5a66b18d0e0d5987ab6 [es: commit message; tweak version check to distinguish 10.x versions] Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-31 11:33:42 +03:00
# Versions up to 10.1 require OLD_ICONV; 10.2 and beyond don't.
# A typical version string looks like "10.2-RELEASE".
ifeq ($(shell expr "$(uname_R)" : '[1-9]\.'),2)
OLD_ICONV = YesPlease
endif
ifeq ($(firstword $(subst -, ,$(uname_R))),10.0)
OLD_ICONV = YesPlease
endif
ifeq ($(firstword $(subst -, ,$(uname_R))),10.1)
OLD_ICONV = YesPlease
endif
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
NO_MEMMEM = YesPlease
BASIC_CFLAGS += -I/usr/local/include
BASIC_LDFLAGS += -L/usr/local/lib
DIR_HAS_BSD_GROUP_SEMANTICS = YesPlease
USE_ST_TIMESPEC = YesPlease
ifeq ($(shell expr "$(uname_R)" : '4\.'),2)
PTHREAD_LIBS = -pthread
NO_UINTMAX_T = YesPlease
NO_STRTOUMAX = YesPlease
endif
PYTHON_PATH = /usr/local/bin/python
config.mak.uname: correct perl path on FreeBSD It looks the the symlink /usr/bin/perl (to /usr/local/bin/perl) has been removed at least on FreeBSD 10.3. See [1] for more information. [1] https://svnweb.freebsd.org/ports/head/UPDATING?r1=386270&r2=386269&pathrev=386270&diff_format=c Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Helped-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-25 19:21:25 +03:00
PERL_PATH = /usr/local/bin/perl
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
HAVE_PATHS_H = YesPlease
configure: support HAVE_BSD_SYSCTL option On BSD-compatible systems some information such as the number of available CPUs may only be available via the sysctl function. Add support for a HAVE_BSD_SYSCTL option complete with autoconf support and include the sys/syctl.h header when the option is enabled to make the sysctl function available. Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-08 10:14:36 +03:00
HAVE_BSD_SYSCTL = YesPlease
exec_cmd: RUNTIME_PREFIX on some POSIX systems Enable Git to resolve its own binary location using a variety of OS-specific and generic methods, including: - procfs via "/proc/self/exe" (Linux) - _NSGetExecutablePath (Darwin) - KERN_PROC_PATHNAME sysctl on BSDs. - argv0, if absolute (all, including Windows). This is used to enable RUNTIME_PREFIX support for non-Windows systems, notably Linux and Darwin. When configured with RUNTIME_PREFIX, Git will do a best-effort resolution of its executable path and automatically use this as its "exec_path" for relative helper and data lookups, unless explicitly overridden. Small incidental formatting cleanup of "exec_cmd.c". Signed-off-by: Dan Jacques <dnj@google.com> Thanks-to: Robbie Iannucci <iannucci@google.com> Thanks-to: Junio C Hamano <gitster@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-10 18:05:44 +03:00
HAVE_BSD_KERN_PROC_SYSCTL = YesPlease
wrapper: add a helper to generate numbers from a CSPRNG There are many situations in which having access to a cryptographically secure pseudorandom number generator (CSPRNG) is helpful. In the future, we'll encounter one of these when dealing with temporary files. To make this possible, let's add a function which reads from a system CSPRNG and returns some bytes. We know that all systems will have such an interface. A CSPRNG is required for a secure TLS or SSH implementation and a Git implementation which provided neither would be of little practical use. In addition, POSIX is set to standardize getentropy(2) in the next version, so in the (potentially distant) future we can rely on that. For systems which lack one of the other interfaces, we provide the ability to use OpenSSL's CSPRNG. OpenSSL is highly portable and functions on practically every known OS, and we know it will have access to some source of cryptographically secure randomness. We also provide support for the arc4random in libbsd for folks who would prefer to use that. Because this is a security sensitive interface, we take some precautions. We either succeed by filling the buffer completely as we requested, or we fail. We don't return partial data because the caller will almost never find that to be a useful behavior. Specify a makefile knob which users can use to specify one or more suitable CSPRNGs, and turn the multiple string options into a set of defines, since we cannot match on strings in the preprocessor. We allow multiple options to make the job of handling this in autoconf easier. The order of options is important here. On systems with arc4random, which is most of the BSDs, we use that, since, except on MirBSD and macOS, it uses ChaCha20, which is extremely fast, and sits entirely in userspace, avoiding a system call. We then prefer getrandom over getentropy, because the former has been available longer on Linux, and then OpenSSL. Finally, if none of those are available, we use /dev/urandom, because most Unix-like operating systems provide that API. We prefer options that don't involve device files when possible because those work in some restricted environments where device files may not be available. Set the configuration variables appropriately for Linux and the BSDs, including macOS, as well as Windows and NonStop. We specifically only consider versions which receive publicly available security support here. For the same reason, we don't specify getrandom(2) on Linux, because CentOS 7 doesn't support it in glibc (although its kernel does) and we don't want to resort to making syscalls. Finally, add a test helper to allow this to be tested by hand and in tests. We don't add any tests, since invoking the CSPRNG is not likely to produce interesting, reproducible results. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-18 00:56:16 +03:00
CSPRNG_METHOD = arc4random
pager: move pager-specific setup into the build Allowing PAGER_ENV to be set at build-time allows us to move pager-specific knowledge out of our build. This allows us to set a better default for FreeBSD more(1), which pretends not to understand ANSI color escapes if the MORE environment variable is left empty, but accepts the same variables as less(1) Originally-from: https://public-inbox.org/git/xmqq61piw4yf.fsf@gitster.dls.corp.google.com/ Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-04 14:40:25 +03:00
PAGER_ENV = LESS=FRX LV=-c MORE=FRX
config.mak.uname: set FREAD_READS_DIRECTORIES for Linux and FreeBSD This variable is added [1] with the assumption that on a sane system, fopen(<dir>, "r") should return NULL. Linux and FreeBSD do not meet this expectation while at least Windows and AIX do. Let's make sure they behave the same way. I only tested one version on Linux (4.7.0 with glibc 2.22) and FreeBSD (11.0) but since GNU/kFreeBSD is fbsd kernel with gnu userspace, I'm pretty sure it shares the same problem. [1] cba22528fa (Add compat/fopen.c which returns NULL on attempt to open directory - 2008-02-08) Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-03 13:16:48 +03:00
FREAD_READS_DIRECTORIES = UnfortunatelyYes
git-compat-util: work around fileno(fp) that is a macro On various BSD's, fileno(fp) is implemented as a macro that directly accesses the fields in the FILE * object, which breaks a function that accepts a "void *fp" parameter and calls fileno(fp) and expect it to work. Work it around by adding a compile-time knob FILENO_IS_A_MACRO that inserts a real helper function in the middle of the callchain. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-12 17:14:41 +03:00
FILENO_IS_A_MACRO = UnfortunatelyYes
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
endif
ifeq ($(uname_S),OpenBSD)
NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
USE_ST_TIMESPEC = YesPlease
NEEDS_LIBICONV = YesPlease
BASIC_CFLAGS += -I/usr/local/include
BASIC_LDFLAGS += -L/usr/local/lib
HAVE_PATHS_H = YesPlease
configure: support HAVE_BSD_SYSCTL option On BSD-compatible systems some information such as the number of available CPUs may only be available via the sysctl function. Add support for a HAVE_BSD_SYSCTL option complete with autoconf support and include the sys/syctl.h header when the option is enabled to make the sysctl function available. Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-08 10:14:36 +03:00
HAVE_BSD_SYSCTL = YesPlease
exec_cmd: RUNTIME_PREFIX on some POSIX systems Enable Git to resolve its own binary location using a variety of OS-specific and generic methods, including: - procfs via "/proc/self/exe" (Linux) - _NSGetExecutablePath (Darwin) - KERN_PROC_PATHNAME sysctl on BSDs. - argv0, if absolute (all, including Windows). This is used to enable RUNTIME_PREFIX support for non-Windows systems, notably Linux and Darwin. When configured with RUNTIME_PREFIX, Git will do a best-effort resolution of its executable path and automatically use this as its "exec_path" for relative helper and data lookups, unless explicitly overridden. Small incidental formatting cleanup of "exec_cmd.c". Signed-off-by: Dan Jacques <dnj@google.com> Thanks-to: Robbie Iannucci <iannucci@google.com> Thanks-to: Junio C Hamano <gitster@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-10 18:05:44 +03:00
HAVE_BSD_KERN_PROC_SYSCTL = YesPlease
wrapper: add a helper to generate numbers from a CSPRNG There are many situations in which having access to a cryptographically secure pseudorandom number generator (CSPRNG) is helpful. In the future, we'll encounter one of these when dealing with temporary files. To make this possible, let's add a function which reads from a system CSPRNG and returns some bytes. We know that all systems will have such an interface. A CSPRNG is required for a secure TLS or SSH implementation and a Git implementation which provided neither would be of little practical use. In addition, POSIX is set to standardize getentropy(2) in the next version, so in the (potentially distant) future we can rely on that. For systems which lack one of the other interfaces, we provide the ability to use OpenSSL's CSPRNG. OpenSSL is highly portable and functions on practically every known OS, and we know it will have access to some source of cryptographically secure randomness. We also provide support for the arc4random in libbsd for folks who would prefer to use that. Because this is a security sensitive interface, we take some precautions. We either succeed by filling the buffer completely as we requested, or we fail. We don't return partial data because the caller will almost never find that to be a useful behavior. Specify a makefile knob which users can use to specify one or more suitable CSPRNGs, and turn the multiple string options into a set of defines, since we cannot match on strings in the preprocessor. We allow multiple options to make the job of handling this in autoconf easier. The order of options is important here. On systems with arc4random, which is most of the BSDs, we use that, since, except on MirBSD and macOS, it uses ChaCha20, which is extremely fast, and sits entirely in userspace, avoiding a system call. We then prefer getrandom over getentropy, because the former has been available longer on Linux, and then OpenSSL. Finally, if none of those are available, we use /dev/urandom, because most Unix-like operating systems provide that API. We prefer options that don't involve device files when possible because those work in some restricted environments where device files may not be available. Set the configuration variables appropriately for Linux and the BSDs, including macOS, as well as Windows and NonStop. We specifically only consider versions which receive publicly available security support here. For the same reason, we don't specify getrandom(2) on Linux, because CentOS 7 doesn't support it in glibc (although its kernel does) and we don't want to resort to making syscalls. Finally, add a test helper to allow this to be tested by hand and in tests. We don't add any tests, since invoking the CSPRNG is not likely to produce interesting, reproducible results. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-18 00:56:16 +03:00
CSPRNG_METHOD = arc4random
exec_cmd: RUNTIME_PREFIX on some POSIX systems Enable Git to resolve its own binary location using a variety of OS-specific and generic methods, including: - procfs via "/proc/self/exe" (Linux) - _NSGetExecutablePath (Darwin) - KERN_PROC_PATHNAME sysctl on BSDs. - argv0, if absolute (all, including Windows). This is used to enable RUNTIME_PREFIX support for non-Windows systems, notably Linux and Darwin. When configured with RUNTIME_PREFIX, Git will do a best-effort resolution of its executable path and automatically use this as its "exec_path" for relative helper and data lookups, unless explicitly overridden. Small incidental formatting cleanup of "exec_cmd.c". Signed-off-by: Dan Jacques <dnj@google.com> Thanks-to: Robbie Iannucci <iannucci@google.com> Thanks-to: Junio C Hamano <gitster@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-10 18:05:44 +03:00
PROCFS_EXECUTABLE_PATH = /proc/curproc/file
config.mak.uname: OpenBSD uses BSD semantics with fread for directories this "fixes" test 23 (proper error on directory "files") from t1308 MirBSD likely also affected but this was only tested with OpenBSD and therefore this specific change only affects that platform the optional 'configure' sets this automatically (tested with 6.1 to 6.4) but considering this is a legacy feature it is likely that it affected all old versions and is probably what most users had been using as a workaround Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-02 05:43:20 +03:00
FREAD_READS_DIRECTORIES = UnfortunatelyYes
git-compat-util: work around fileno(fp) that is a macro On various BSD's, fileno(fp) is implemented as a macro that directly accesses the fields in the FILE * object, which breaks a function that accepts a "void *fp" parameter and calls fileno(fp) and expect it to work. Work it around by adding a compile-time knob FILENO_IS_A_MACRO that inserts a real helper function in the middle of the callchain. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-12 17:14:41 +03:00
FILENO_IS_A_MACRO = UnfortunatelyYes
Add MirBSD support to the build system. Add an entry into the table of supported OSes. Do not set _XOPEN_SOURCE (contrary to OpenBSD) because that disables the u_short and u_long typedefs, which are used unconditionally in various other header files. Signed-off-by: Benny Siegert <bsiegert@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-31 18:36:45 +04:00
endif
ifeq ($(uname_S),MirBSD)
NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
USE_ST_TIMESPEC = YesPlease
NEEDS_LIBICONV = YesPlease
HAVE_PATHS_H = YesPlease
configure: support HAVE_BSD_SYSCTL option On BSD-compatible systems some information such as the number of available CPUs may only be available via the sysctl function. Add support for a HAVE_BSD_SYSCTL option complete with autoconf support and include the sys/syctl.h header when the option is enabled to make the sysctl function available. Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-08 10:14:36 +03:00
HAVE_BSD_SYSCTL = YesPlease
wrapper: add a helper to generate numbers from a CSPRNG There are many situations in which having access to a cryptographically secure pseudorandom number generator (CSPRNG) is helpful. In the future, we'll encounter one of these when dealing with temporary files. To make this possible, let's add a function which reads from a system CSPRNG and returns some bytes. We know that all systems will have such an interface. A CSPRNG is required for a secure TLS or SSH implementation and a Git implementation which provided neither would be of little practical use. In addition, POSIX is set to standardize getentropy(2) in the next version, so in the (potentially distant) future we can rely on that. For systems which lack one of the other interfaces, we provide the ability to use OpenSSL's CSPRNG. OpenSSL is highly portable and functions on practically every known OS, and we know it will have access to some source of cryptographically secure randomness. We also provide support for the arc4random in libbsd for folks who would prefer to use that. Because this is a security sensitive interface, we take some precautions. We either succeed by filling the buffer completely as we requested, or we fail. We don't return partial data because the caller will almost never find that to be a useful behavior. Specify a makefile knob which users can use to specify one or more suitable CSPRNGs, and turn the multiple string options into a set of defines, since we cannot match on strings in the preprocessor. We allow multiple options to make the job of handling this in autoconf easier. The order of options is important here. On systems with arc4random, which is most of the BSDs, we use that, since, except on MirBSD and macOS, it uses ChaCha20, which is extremely fast, and sits entirely in userspace, avoiding a system call. We then prefer getrandom over getentropy, because the former has been available longer on Linux, and then OpenSSL. Finally, if none of those are available, we use /dev/urandom, because most Unix-like operating systems provide that API. We prefer options that don't involve device files when possible because those work in some restricted environments where device files may not be available. Set the configuration variables appropriately for Linux and the BSDs, including macOS, as well as Windows and NonStop. We specifically only consider versions which receive publicly available security support here. For the same reason, we don't specify getrandom(2) on Linux, because CentOS 7 doesn't support it in glibc (although its kernel does) and we don't want to resort to making syscalls. Finally, add a test helper to allow this to be tested by hand and in tests. We don't add any tests, since invoking the CSPRNG is not likely to produce interesting, reproducible results. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-18 00:56:16 +03:00
CSPRNG_METHOD = arc4random
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
endif
ifeq ($(uname_S),NetBSD)
ifeq ($(shell expr "$(uname_R)" : '[01]\.'),2)
NEEDS_LIBICONV = YesPlease
endif
BASIC_CFLAGS += -I/usr/pkg/include
BASIC_LDFLAGS += -L/usr/pkg/lib $(CC_LD_DYNPATH)/usr/pkg/lib
USE_ST_TIMESPEC = YesPlease
HAVE_PATHS_H = YesPlease
configure: support HAVE_BSD_SYSCTL option On BSD-compatible systems some information such as the number of available CPUs may only be available via the sysctl function. Add support for a HAVE_BSD_SYSCTL option complete with autoconf support and include the sys/syctl.h header when the option is enabled to make the sysctl function available. Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-08 10:14:36 +03:00
HAVE_BSD_SYSCTL = YesPlease
exec_cmd: RUNTIME_PREFIX on some POSIX systems Enable Git to resolve its own binary location using a variety of OS-specific and generic methods, including: - procfs via "/proc/self/exe" (Linux) - _NSGetExecutablePath (Darwin) - KERN_PROC_PATHNAME sysctl on BSDs. - argv0, if absolute (all, including Windows). This is used to enable RUNTIME_PREFIX support for non-Windows systems, notably Linux and Darwin. When configured with RUNTIME_PREFIX, Git will do a best-effort resolution of its executable path and automatically use this as its "exec_path" for relative helper and data lookups, unless explicitly overridden. Small incidental formatting cleanup of "exec_cmd.c". Signed-off-by: Dan Jacques <dnj@google.com> Thanks-to: Robbie Iannucci <iannucci@google.com> Thanks-to: Junio C Hamano <gitster@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-10 18:05:44 +03:00
HAVE_BSD_KERN_PROC_SYSCTL = YesPlease
wrapper: add a helper to generate numbers from a CSPRNG There are many situations in which having access to a cryptographically secure pseudorandom number generator (CSPRNG) is helpful. In the future, we'll encounter one of these when dealing with temporary files. To make this possible, let's add a function which reads from a system CSPRNG and returns some bytes. We know that all systems will have such an interface. A CSPRNG is required for a secure TLS or SSH implementation and a Git implementation which provided neither would be of little practical use. In addition, POSIX is set to standardize getentropy(2) in the next version, so in the (potentially distant) future we can rely on that. For systems which lack one of the other interfaces, we provide the ability to use OpenSSL's CSPRNG. OpenSSL is highly portable and functions on practically every known OS, and we know it will have access to some source of cryptographically secure randomness. We also provide support for the arc4random in libbsd for folks who would prefer to use that. Because this is a security sensitive interface, we take some precautions. We either succeed by filling the buffer completely as we requested, or we fail. We don't return partial data because the caller will almost never find that to be a useful behavior. Specify a makefile knob which users can use to specify one or more suitable CSPRNGs, and turn the multiple string options into a set of defines, since we cannot match on strings in the preprocessor. We allow multiple options to make the job of handling this in autoconf easier. The order of options is important here. On systems with arc4random, which is most of the BSDs, we use that, since, except on MirBSD and macOS, it uses ChaCha20, which is extremely fast, and sits entirely in userspace, avoiding a system call. We then prefer getrandom over getentropy, because the former has been available longer on Linux, and then OpenSSL. Finally, if none of those are available, we use /dev/urandom, because most Unix-like operating systems provide that API. We prefer options that don't involve device files when possible because those work in some restricted environments where device files may not be available. Set the configuration variables appropriately for Linux and the BSDs, including macOS, as well as Windows and NonStop. We specifically only consider versions which receive publicly available security support here. For the same reason, we don't specify getrandom(2) on Linux, because CentOS 7 doesn't support it in glibc (although its kernel does) and we don't want to resort to making syscalls. Finally, add a test helper to allow this to be tested by hand and in tests. We don't add any tests, since invoking the CSPRNG is not likely to produce interesting, reproducible results. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-18 00:56:16 +03:00
CSPRNG_METHOD = arc4random
exec_cmd: RUNTIME_PREFIX on some POSIX systems Enable Git to resolve its own binary location using a variety of OS-specific and generic methods, including: - procfs via "/proc/self/exe" (Linux) - _NSGetExecutablePath (Darwin) - KERN_PROC_PATHNAME sysctl on BSDs. - argv0, if absolute (all, including Windows). This is used to enable RUNTIME_PREFIX support for non-Windows systems, notably Linux and Darwin. When configured with RUNTIME_PREFIX, Git will do a best-effort resolution of its executable path and automatically use this as its "exec_path" for relative helper and data lookups, unless explicitly overridden. Small incidental formatting cleanup of "exec_cmd.c". Signed-off-by: Dan Jacques <dnj@google.com> Thanks-to: Robbie Iannucci <iannucci@google.com> Thanks-to: Junio C Hamano <gitster@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-10 18:05:44 +03:00
PROCFS_EXECUTABLE_PATH = /proc/curproc/exe
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
endif
ifeq ($(uname_S),AIX)
DEFAULT_PAGER = more
NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
NO_MKDTEMP = YesPlease
NO_STRLCPY = YesPlease
NO_NSEC = YesPlease
config.mak.uname: set NO_REGEX=NeedsStartEnd on AIX Set the NO_REGEX=NeedsStartEnd Makefile flag by default on AIX. Since commit 2f8952250a ("regex: add regexec_buf() that can work on a non NUL-terminated string", 2016-09-21) git has errored out at compile-time if the regular expression library doesn't support REG_STARTEND. While looking through Google search results for the use of NO_REGEX I found a Chef recipe that set this on AIX[1], looking through the documentation for the latest version of AIX (7.2, released October 2015) shows that its regexec() doesn't have REG_STARTEND. 1. https://github.com/chef/omnibus-software/commit/e247e36761#diff-3df898345d670979b74acc0bf71d8c47 2. https://www.ibm.com/support/knowledgecenter/ssw_aix_72/com.ibm.aix.basetrf2/regexec.htm Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-03 16:54:30 +03:00
NO_REGEX = NeedsStartEnd
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
FREAD_READS_DIRECTORIES = UnfortunatelyYes
INTERNAL_QSORT = UnfortunatelyYes
NEEDS_LIBICONV = YesPlease
BASIC_CFLAGS += -D_LARGE_FILES
Makefile: use fileno macro work around on AIX Declare FILENO_IS_A_MACRO on AIX On AIX, fileno(fp) is a macro and need to use the work around already made for BSD's. Signed-off-by: Clément Chigot <clement.chigot@atos.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-18 11:55:09 +03:00
FILENO_IS_A_MACRO = UnfortunatelyYes
git-compat-util: work around for access(X_OK) under root On AIX, access(X_OK) may succeed when run as root even if the execution isn't possible. This behavior is allowed by POSIX which says: ... for a process with appropriate privileges, an implementation may indicate success for X_OK even if execute permission is not granted to any user. It can lead hook programs to have their execution refused: git commit -m content fatal: cannot exec '.git/hooks/pre-commit': Permission denied Add NEED_ACCESS_ROOT_HANDLER in order to use an access helper function. It checks with stat if any executable flags is set when the current user is root. Signed-off-by: Clément Chigot <clement.chigot@atos.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-25 10:01:56 +03:00
NEED_ACCESS_ROOT_HANDLER = UnfortunatelyYes
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
ifeq ($(shell expr "$(uname_V)" : '[1234]'),1)
NO_PTHREADS = YesPlease
else
PTHREAD_LIBS = -lpthread
endif
ifeq ($(shell expr "$(uname_V).$(uname_R)" : '5\.1'),3)
INLINE = ''
endif
GIT_TEST_CMP = cmp
endif
ifeq ($(uname_S),GNU)
# GNU/Hurd
Portable alloca for Git In the next patch we'll have to use alloca() for performance reasons, but since alloca is non-standardized and is not portable, let's have a trick with compatibility wrappers: 1. at configure time, determine, do we have working alloca() through alloca.h, and define #define HAVE_ALLOCA_H if yes. 2. in code #ifdef HAVE_ALLOCA_H # include <alloca.h> # define xalloca(size) (alloca(size)) # define xalloca_free(p) do {} while(0) #else # define xalloca(size) (xmalloc(size)) # define xalloca_free(p) (free(p)) #endif and use it like func() { p = xalloca(size); ... xalloca_free(p); } This way, for systems, where alloca is available, we'll have optimal on-stack allocations with fast executions. On the other hand, on systems, where alloca is not available, this gracefully fallbacks to xmalloc/free. Both autoconf and config.mak.uname configurations were updated. For autoconf, we are not bothering considering cases, when no alloca.h is available, but alloca() works some other way - its simply alloca.h is available and works or not, everything else is deep legacy. For config.mak.uname, I've tried to make my almost-sure guess for where alloca() is available, but since I only have access to Linux it is the only change I can be sure about myself, with relevant to other changed systems people Cc'ed. NOTE SunOS and Windows had explicit -DHAVE_ALLOCA_H in their configurations. I've changed that to now-common HAVE_ALLOCA_H=YesPlease which should be correct. Cc: Brandon Casey <drafnel@gmail.com> Cc: Marius Storm-Olsen <mstormo@gmail.com> Cc: Johannes Sixt <j6t@kdbg.org> Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de> Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Cc: Gerrit Pape <pape@smarden.org> Cc: Petr Salinger <Petr.Salinger@seznam.cz> Cc: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Thomas Schwinge <thomas@codesourcery.com> (GNU Hurd changes) Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-27 18:22:50 +04:00
HAVE_ALLOCA_H = YesPlease
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
NO_STRLCPY = YesPlease
HAVE_PATHS_H = YesPlease
LIBC_CONTAINS_LIBINTL = YesPlease
config.mak.uname: Define FREAD_READS_DIRECTORIES for GNU/Hurd GNU/Hurd is another platform that behaves like this. Set it to UnfortunatelyYes so that config directory files are correctly processed. This fixes the corresponding 'proper error on directory "files"' test in t1308-config-set.sh. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-22 18:33:47 +03:00
FREAD_READS_DIRECTORIES = UnfortunatelyYes
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
endif
ifeq ($(uname_S),IRIX)
NO_SETENV = YesPlease
NO_UNSETENV = YesPlease
NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
NO_MKDTEMP = YesPlease
# When compiled with the MIPSpro 7.4.4m compiler, and without pthreads
# (i.e. NO_PTHREADS is set), and _with_ MMAP (i.e. NO_MMAP is not set),
# git dies with a segmentation fault when trying to access the first
# entry of a reflog. The conservative choice is made to always set
# NO_MMAP. If you suspect that your compiler is not affected by this
# issue, comment out the NO_MMAP statement.
NO_MMAP = YesPlease
NO_REGEX = YesPlease
SNPRINTF_RETURNS_BOGUS = YesPlease
SHELL_PATH = /usr/gnu/bin/bash
NEEDS_LIBGEN = YesPlease
endif
ifeq ($(uname_S),IRIX64)
NO_SETENV = YesPlease
NO_UNSETENV = YesPlease
NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
NO_MKDTEMP = YesPlease
# When compiled with the MIPSpro 7.4.4m compiler, and without pthreads
# (i.e. NO_PTHREADS is set), and _with_ MMAP (i.e. NO_MMAP is not set),
# git dies with a segmentation fault when trying to access the first
# entry of a reflog. The conservative choice is made to always set
# NO_MMAP. If you suspect that your compiler is not affected by this
# issue, comment out the NO_MMAP statement.
NO_MMAP = YesPlease
NO_REGEX = YesPlease
SNPRINTF_RETURNS_BOGUS = YesPlease
SHELL_PATH = /usr/gnu/bin/bash
NEEDS_LIBGEN = YesPlease
endif
ifeq ($(uname_S),HP-UX)
INLINE = __inline
NO_IPV6 = YesPlease
NO_SETENV = YesPlease
NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
NO_STRLCPY = YesPlease
NO_MKDTEMP = YesPlease
NO_UNSETENV = YesPlease
NO_HSTRERROR = YesPlease
NO_SYS_SELECT_H = YesPlease
SNPRINTF_RETURNS_BOGUS = YesPlease
NO_NSEC = YesPlease
ifeq ($(uname_R),B.11.00)
NO_INET_NTOP = YesPlease
NO_INET_PTON = YesPlease
endif
ifeq ($(uname_R),B.10.20)
# Override HP-UX 11.x setting:
INLINE =
SOCKLEN_T = size_t
NO_PREAD = YesPlease
NO_INET_NTOP = YesPlease
NO_INET_PTON = YesPlease
endif
GIT_TEST_CMP = cmp
endif
ifeq ($(uname_S),Windows)
GIT_VERSION := $(GIT_VERSION).MSVC
pathsep = ;
msvc: support building Git using MS Visual C++ With this patch, Git can be built using the Microsoft toolchain, via: make MSVC=1 [DEBUG=1] Third party libraries are built from source using the open source "vcpkg" tool set. See https://github.com/Microsoft/vcpkg On a first build, the vcpkg tools and the third party libraries are automatically downloaded and built. DLLs for the third party libraries are copied to the top-level (and t/helper) directory to facilitate debugging. See compat/vcbuild/README. A series of .bat files are invoked by the Makefile to find the location of the installed version of Visual Studio and the associated compiler tools (essentially replicating the environment setup performed by a "Developer Command Prompt"). This should find the most recent VS2015 or VS2017 installation. Output from these scripts are used by the Makefile to define compiler and linker pathnames and -I and -L arguments. The build produces .pdb files for both debug and release builds. Note: This commit was squashed from an organic series of commits developed between 2016 and 2018 in Git for Windows' `master` branch. This combined commit eliminates the obsolete commits related to fetching NuGet packages for third party libraries. It is difficult to use NuGet packages for C/C++ sources because they may be built by earlier versions of the MSVC compiler and have CRT version and linking issues. Additionally, the C/C++ NuGet packages that we were using tended to not be updated concurrently with the sources. And in the case of cURL and OpenSSL, this could expose us to security issues. Helped-by: Yue Lin Ho <b8732003@student.nsysu.edu.tw> Helped-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-25 17:49:39 +03:00
# Assume that this is built in Git for Windows' SDK
ifeq (MINGW32,$(MSYSTEM))
prefix = /mingw32
else
prefix = /mingw64
endif
# Prepend MSVC 64-bit tool-chain to PATH.
#
# A regular Git Bash *does not* have cl.exe in its $PATH. As there is a
# link.exe next to, and required by, cl.exe, we have to prepend this
# onto the existing $PATH.
#
SANE_TOOL_PATH ?= $(msvc_bin_dir_msys)
Portable alloca for Git In the next patch we'll have to use alloca() for performance reasons, but since alloca is non-standardized and is not portable, let's have a trick with compatibility wrappers: 1. at configure time, determine, do we have working alloca() through alloca.h, and define #define HAVE_ALLOCA_H if yes. 2. in code #ifdef HAVE_ALLOCA_H # include <alloca.h> # define xalloca(size) (alloca(size)) # define xalloca_free(p) do {} while(0) #else # define xalloca(size) (xmalloc(size)) # define xalloca_free(p) (free(p)) #endif and use it like func() { p = xalloca(size); ... xalloca_free(p); } This way, for systems, where alloca is available, we'll have optimal on-stack allocations with fast executions. On the other hand, on systems, where alloca is not available, this gracefully fallbacks to xmalloc/free. Both autoconf and config.mak.uname configurations were updated. For autoconf, we are not bothering considering cases, when no alloca.h is available, but alloca() works some other way - its simply alloca.h is available and works or not, everything else is deep legacy. For config.mak.uname, I've tried to make my almost-sure guess for where alloca() is available, but since I only have access to Linux it is the only change I can be sure about myself, with relevant to other changed systems people Cc'ed. NOTE SunOS and Windows had explicit -DHAVE_ALLOCA_H in their configurations. I've changed that to now-common HAVE_ALLOCA_H=YesPlease which should be correct. Cc: Brandon Casey <drafnel@gmail.com> Cc: Marius Storm-Olsen <mstormo@gmail.com> Cc: Johannes Sixt <j6t@kdbg.org> Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de> Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Cc: Gerrit Pape <pape@smarden.org> Cc: Petr Salinger <Petr.Salinger@seznam.cz> Cc: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Thomas Schwinge <thomas@codesourcery.com> (GNU Hurd changes) Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-27 18:22:50 +04:00
HAVE_ALLOCA_H = YesPlease
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
NO_PREAD = YesPlease
NEEDS_CRYPTO_WITH_SSL = YesPlease
NO_LIBGEN_H = YesPlease
NO_POLL = YesPlease
NO_SYMLINK_HEAD = YesPlease
NO_IPV6 = YesPlease
NO_UNIX_SOCKETS = YesPlease
NO_SETENV = YesPlease
NO_STRCASESTR = YesPlease
NO_STRLCPY = YesPlease
NO_MEMMEM = YesPlease
msvc: support building Git using MS Visual C++ With this patch, Git can be built using the Microsoft toolchain, via: make MSVC=1 [DEBUG=1] Third party libraries are built from source using the open source "vcpkg" tool set. See https://github.com/Microsoft/vcpkg On a first build, the vcpkg tools and the third party libraries are automatically downloaded and built. DLLs for the third party libraries are copied to the top-level (and t/helper) directory to facilitate debugging. See compat/vcbuild/README. A series of .bat files are invoked by the Makefile to find the location of the installed version of Visual Studio and the associated compiler tools (essentially replicating the environment setup performed by a "Developer Command Prompt"). This should find the most recent VS2015 or VS2017 installation. Output from these scripts are used by the Makefile to define compiler and linker pathnames and -I and -L arguments. The build produces .pdb files for both debug and release builds. Note: This commit was squashed from an organic series of commits developed between 2016 and 2018 in Git for Windows' `master` branch. This combined commit eliminates the obsolete commits related to fetching NuGet packages for third party libraries. It is difficult to use NuGet packages for C/C++ sources because they may be built by earlier versions of the MSVC compiler and have CRT version and linking issues. Additionally, the C/C++ NuGet packages that we were using tended to not be updated concurrently with the sources. And in the case of cURL and OpenSSL, this could expose us to security issues. Helped-by: Yue Lin Ho <b8732003@student.nsysu.edu.tw> Helped-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-25 17:49:39 +03:00
NEEDS_LIBICONV = YesPlease
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
NO_STRTOUMAX = YesPlease
NO_MKDTEMP = YesPlease
msvc: support building Git using MS Visual C++ With this patch, Git can be built using the Microsoft toolchain, via: make MSVC=1 [DEBUG=1] Third party libraries are built from source using the open source "vcpkg" tool set. See https://github.com/Microsoft/vcpkg On a first build, the vcpkg tools and the third party libraries are automatically downloaded and built. DLLs for the third party libraries are copied to the top-level (and t/helper) directory to facilitate debugging. See compat/vcbuild/README. A series of .bat files are invoked by the Makefile to find the location of the installed version of Visual Studio and the associated compiler tools (essentially replicating the environment setup performed by a "Developer Command Prompt"). This should find the most recent VS2015 or VS2017 installation. Output from these scripts are used by the Makefile to define compiler and linker pathnames and -I and -L arguments. The build produces .pdb files for both debug and release builds. Note: This commit was squashed from an organic series of commits developed between 2016 and 2018 in Git for Windows' `master` branch. This combined commit eliminates the obsolete commits related to fetching NuGet packages for third party libraries. It is difficult to use NuGet packages for C/C++ sources because they may be built by earlier versions of the MSVC compiler and have CRT version and linking issues. Additionally, the C/C++ NuGet packages that we were using tended to not be updated concurrently with the sources. And in the case of cURL and OpenSSL, this could expose us to security issues. Helped-by: Yue Lin Ho <b8732003@student.nsysu.edu.tw> Helped-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-25 17:49:39 +03:00
NO_INTTYPES_H = YesPlease
wrapper: add a helper to generate numbers from a CSPRNG There are many situations in which having access to a cryptographically secure pseudorandom number generator (CSPRNG) is helpful. In the future, we'll encounter one of these when dealing with temporary files. To make this possible, let's add a function which reads from a system CSPRNG and returns some bytes. We know that all systems will have such an interface. A CSPRNG is required for a secure TLS or SSH implementation and a Git implementation which provided neither would be of little practical use. In addition, POSIX is set to standardize getentropy(2) in the next version, so in the (potentially distant) future we can rely on that. For systems which lack one of the other interfaces, we provide the ability to use OpenSSL's CSPRNG. OpenSSL is highly portable and functions on practically every known OS, and we know it will have access to some source of cryptographically secure randomness. We also provide support for the arc4random in libbsd for folks who would prefer to use that. Because this is a security sensitive interface, we take some precautions. We either succeed by filling the buffer completely as we requested, or we fail. We don't return partial data because the caller will almost never find that to be a useful behavior. Specify a makefile knob which users can use to specify one or more suitable CSPRNGs, and turn the multiple string options into a set of defines, since we cannot match on strings in the preprocessor. We allow multiple options to make the job of handling this in autoconf easier. The order of options is important here. On systems with arc4random, which is most of the BSDs, we use that, since, except on MirBSD and macOS, it uses ChaCha20, which is extremely fast, and sits entirely in userspace, avoiding a system call. We then prefer getrandom over getentropy, because the former has been available longer on Linux, and then OpenSSL. Finally, if none of those are available, we use /dev/urandom, because most Unix-like operating systems provide that API. We prefer options that don't involve device files when possible because those work in some restricted environments where device files may not be available. Set the configuration variables appropriately for Linux and the BSDs, including macOS, as well as Windows and NonStop. We specifically only consider versions which receive publicly available security support here. For the same reason, we don't specify getrandom(2) on Linux, because CentOS 7 doesn't support it in glibc (although its kernel does) and we don't want to resort to making syscalls. Finally, add a test helper to allow this to be tested by hand and in tests. We don't add any tests, since invoking the CSPRNG is not likely to produce interesting, reproducible results. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-18 00:56:16 +03:00
CSPRNG_METHOD = rtlgenrandom
msvc: support building Git using MS Visual C++ With this patch, Git can be built using the Microsoft toolchain, via: make MSVC=1 [DEBUG=1] Third party libraries are built from source using the open source "vcpkg" tool set. See https://github.com/Microsoft/vcpkg On a first build, the vcpkg tools and the third party libraries are automatically downloaded and built. DLLs for the third party libraries are copied to the top-level (and t/helper) directory to facilitate debugging. See compat/vcbuild/README. A series of .bat files are invoked by the Makefile to find the location of the installed version of Visual Studio and the associated compiler tools (essentially replicating the environment setup performed by a "Developer Command Prompt"). This should find the most recent VS2015 or VS2017 installation. Output from these scripts are used by the Makefile to define compiler and linker pathnames and -I and -L arguments. The build produces .pdb files for both debug and release builds. Note: This commit was squashed from an organic series of commits developed between 2016 and 2018 in Git for Windows' `master` branch. This combined commit eliminates the obsolete commits related to fetching NuGet packages for third party libraries. It is difficult to use NuGet packages for C/C++ sources because they may be built by earlier versions of the MSVC compiler and have CRT version and linking issues. Additionally, the C/C++ NuGet packages that we were using tended to not be updated concurrently with the sources. And in the case of cURL and OpenSSL, this could expose us to security issues. Helped-by: Yue Lin Ho <b8732003@student.nsysu.edu.tw> Helped-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-25 17:49:39 +03:00
# VS2015 with UCRT claims that snprintf and friends are C99 compliant,
# so we don't need this:
#
# SNPRINTF_RETURNS_BOGUS = YesPlease
compat/fsmonitor/fsm-listen-win32: stub in backend for Windows Stub in empty filesystem listener backend for fsmonitor--daemon on Windows. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-25 21:02:51 +03:00
# The builtin FSMonitor requires Named Pipes and Threads on Windows.
# These are always available, so we do not have to conditionally
# support it.
FSMONITOR_DAEMON_BACKEND = win32
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
NO_SVN_TESTS = YesPlease
RUNTIME_PREFIX = YesPlease
mingw/msvc: use the new-style RUNTIME_PREFIX helper This change also allows us to stop overriding argv[0] with the absolute path of the executable, allowing us to preserve e.g. the case of the executable's file name. This fixes https://github.com/git-for-windows/git/issues/1496 partially. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-10 18:05:46 +03:00
HAVE_WPGMPTR = YesWeDo
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
simple-ipc: add win32 implementation Create Windows implementation of "simple-ipc" using named pipes. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-16 00:08:23 +03:00
USE_WIN32_IPC = YesPlease
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
USE_WIN32_MMAP = YesPlease
packed_ref_cache: keep the `packed-refs` file mmapped if possible Keep a copy of the `packed-refs` file contents in memory for as long as a `packed_ref_cache` object is in use: * If the system allows it, keep the `packed-refs` file mmapped. * If not (either because the system doesn't support `mmap()` at all, or because a file that is currently mmapped cannot be replaced via `rename()`), then make a copy of the file's contents in heap-allocated space, and keep that around instead. We base the choice of behavior on a new build-time switch, `MMAP_PREVENTS_DELETE`. By default, this switch is set for Windows variants. After this commit, `MMAP_NONE` and `MMAP_TEMPORARY` are still handled identically. But the next commit will introduce a difference. This whole change is still pointless, because we only read the `packed-refs` file contents immediately after instantiating the `packed_ref_cache`. But that will soon change. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-25 11:00:10 +03:00
MMAP_PREVENTS_DELETE = UnfortunatelyYes
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
# USE_NED_ALLOCATOR = YesPlease
UNRELIABLE_FSTAT = UnfortunatelyYes
OBJECT_CREATION_USES_RENAMES = UnfortunatelyNeedsTo
NO_REGEX = YesPlease
MSVC: fix compile errors due to missing libintl.h Set NO_GETTEXT in config.mak.uname to get rid of libintl.h dependency. Signed-off-by: Karsten Blees <blees@dcon.de> Acked-by: Sebastian Schuberth <sschuberth@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-11 03:21:53 +04:00
NO_GETTEXT = YesPlease
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
NO_PYTHON = YesPlease
msvc: avoid collisions between "tags" and "TAGS" Commit 2f769195 ("MinGW: avoid collisions between "tags" and "TAGS", 28-09-2010) enabled MinGW to use an ETAGS file in order to avoid filename collisions on (Windows) case insensitive filesystems. In addition, this prevents 'make' from issuing several warning messages. When using the Makefile to perform an MSVC build, which is usually executed using MinGW tools, we can also benefit from this capability. In order to reap the above benefits, we set the ETAGS_TARGET build variable to ETAGS in the MSVC config block. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Tested-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-31 22:33:57 +04:00
ETAGS_TARGET = ETAGS
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
NO_POSIX_GOODIES = UnfortunatelyYes
NATIVE_CRLF = YesPlease
DEFAULT_HELP_FORMAT = html
mingw: move Git for Windows' system config where users expect it Git for Windows' prefix is `/mingw64/` (or `/mingw32/` for 32-bit versions), therefore the system config is located at the clunky location `C:\Program Files\Git\mingw64\etc\gitconfig`. This moves the system config into a more logical location: the `mingw64` part of `C:\Program Files\Git\mingw64\etc\gitconfig` never made sense, as it is a mere implementation detail. Let's skip the `mingw64` part and move this to `C:\Program Files\Git\etc\gitconfig`. Side note: in the rare (and not recommended) case a user chooses to install 32-bit Git for Windows on a 64-bit system, the path will of course be `C:\Program Files (x86)\Git\etc\gitconfig`. Background: During the Git for Windows v1.x days, the system config was located at `C:\Program Files (x86)\Git\etc\gitconfig`. With Git for Windows v2.x, it moved to `C:\Program Files\Git\mingw64\gitconfig` (or `C:\Program Files (x86)\Git\mingw32\gitconfig`). Rather than fixing it back then, we tried to introduce a "Windows-wide" config, but that never caught on. Likewise, we move the system `gitattributes` into the same directory. Obviously, we are cautious to do this only for the known install locations `/mingw64` and `/mingw32`; If anybody wants to override that while building their version of Git (e.g. via `make prefix=$HOME`), we leave the default location of the system config and gitattributes alone. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-06-22 13:46:46 +03:00
ifeq (/mingw64,$(subst 32,64,$(prefix)))
# Move system config into top-level /etc/
ETC_GITCONFIG = ../etc/gitconfig
ETC_GITATTRIBUTES = ../etc/gitattributes
endif
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
CC = compat/vcbuild/scripts/clink.pl
AR = compat/vcbuild/scripts/lib.pl
CFLAGS =
msvc: support building Git using MS Visual C++ With this patch, Git can be built using the Microsoft toolchain, via: make MSVC=1 [DEBUG=1] Third party libraries are built from source using the open source "vcpkg" tool set. See https://github.com/Microsoft/vcpkg On a first build, the vcpkg tools and the third party libraries are automatically downloaded and built. DLLs for the third party libraries are copied to the top-level (and t/helper) directory to facilitate debugging. See compat/vcbuild/README. A series of .bat files are invoked by the Makefile to find the location of the installed version of Visual Studio and the associated compiler tools (essentially replicating the environment setup performed by a "Developer Command Prompt"). This should find the most recent VS2015 or VS2017 installation. Output from these scripts are used by the Makefile to define compiler and linker pathnames and -I and -L arguments. The build produces .pdb files for both debug and release builds. Note: This commit was squashed from an organic series of commits developed between 2016 and 2018 in Git for Windows' `master` branch. This combined commit eliminates the obsolete commits related to fetching NuGet packages for third party libraries. It is difficult to use NuGet packages for C/C++ sources because they may be built by earlier versions of the MSVC compiler and have CRT version and linking issues. Additionally, the C/C++ NuGet packages that we were using tended to not be updated concurrently with the sources. And in the case of cURL and OpenSSL, this could expose us to security issues. Helped-by: Yue Lin Ho <b8732003@student.nsysu.edu.tw> Helped-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-25 17:49:39 +03:00
BASIC_CFLAGS = -nologo -I. -Icompat/vcbuild/include -DWIN32 -D_CONSOLE -DHAVE_STRING_H -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
COMPAT_OBJS = compat/msvc.o compat/winansi.o \
core.fsyncmethod: add writeout-only mode This commit introduces the `core.fsyncMethod` configuration knob, which can currently be set to `fsync` or `writeout-only`. The new writeout-only mode attempts to tell the operating system to flush its in-memory page cache to the storage hardware without issuing a CACHE_FLUSH command to the storage controller. Writeout-only fsync is significantly faster than a vanilla fsync on common hardware, since data is written to a disk-side cache rather than all the way to a durable medium. Later changes in this patch series will take advantage of this primitive to implement batching of hardware flushes. When git_fsync is called with FSYNC_WRITEOUT_ONLY, it may fail and the caller is expected to do an ordinary fsync as needed. On Apple platforms, the fsync system call does not issue a CACHE_FLUSH directive to the storage controller. This change updates fsync to do fcntl(F_FULLFSYNC) to make fsync actually durable. We maintain parity with existing behavior on Apple platforms by setting the default value of the new core.fsyncMethod option. Signed-off-by: Neeraj Singh <neerajsi@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-11 01:43:20 +03:00
compat/win32/flush.o \
MSVC: include compat/win32/path-utils.h for MSVC, too, for real_path() A path such as 'c:/somepath/submodule/../.git/modules/submodule' wasn't resolved correctly any more, because the *nix variant of offset_1st_component is used instead of the Win32 specific version. Regression was introduced in commit 1cadad6f6 when mingw_offset_1st_component was moved from mingw.c which is included by msvc.c to a separate file. Then, the new file "compat/win32/path-utils.h" was only included for the __CYGWIN__ and __MINGW32__ cases in git-compat-util.h, the case for _MSC_VER was missing. Signed-off-by: Sven Strickroth <email@cs-ware.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-08 14:26:16 +03:00
compat/win32/path-utils.o \
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
compat/win32/pthread.o compat/win32/syslog.o \
trace2: collect Windows-specific process information Add platform-specific interface to log information about the current process. On Windows, this interface is used to indicate whether the git process is running under a debugger and list names of the process ancestors. Information for other platforms is left for a future effort. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-23 01:25:02 +03:00
compat/win32/trace2_win32_process_info.o \
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
compat/win32/dirent.o
msvc: support building Git using MS Visual C++ With this patch, Git can be built using the Microsoft toolchain, via: make MSVC=1 [DEBUG=1] Third party libraries are built from source using the open source "vcpkg" tool set. See https://github.com/Microsoft/vcpkg On a first build, the vcpkg tools and the third party libraries are automatically downloaded and built. DLLs for the third party libraries are copied to the top-level (and t/helper) directory to facilitate debugging. See compat/vcbuild/README. A series of .bat files are invoked by the Makefile to find the location of the installed version of Visual Studio and the associated compiler tools (essentially replicating the environment setup performed by a "Developer Command Prompt"). This should find the most recent VS2015 or VS2017 installation. Output from these scripts are used by the Makefile to define compiler and linker pathnames and -I and -L arguments. The build produces .pdb files for both debug and release builds. Note: This commit was squashed from an organic series of commits developed between 2016 and 2018 in Git for Windows' `master` branch. This combined commit eliminates the obsolete commits related to fetching NuGet packages for third party libraries. It is difficult to use NuGet packages for C/C++ sources because they may be built by earlier versions of the MSVC compiler and have CRT version and linking issues. Additionally, the C/C++ NuGet packages that we were using tended to not be updated concurrently with the sources. And in the case of cURL and OpenSSL, this could expose us to security issues. Helped-by: Yue Lin Ho <b8732003@student.nsysu.edu.tw> Helped-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-25 17:49:39 +03:00
COMPAT_CFLAGS = -D__USE_MINGW_ACCESS -DDETECT_MSYS_TTY -DNOGDI -DHAVE_STRING_H -Icompat -Icompat/regex -Icompat/win32 -DSTRIP_EXTENSION=\".exe\"
mingw: replace mingw_startup() hack Git for Windows has special code to retrieve the command-line parameters (and even the environment) in UTF-16 encoding, so that they can be converted to UTF-8. This is necessary because Git for Windows wants to use UTF-8 encoded strings throughout its code, and the main() function does not get the parameters in that encoding. To do that, we used the __wgetmainargs() function, which is not even a Win32 API function, but provided by the MINGW "runtime" instead. Obviously, this method would not work with any compiler other than GCC, and in preparation for compiling with Visual C++, we would like to avoid precisely that. Lucky us, there is a much more elegant way: we can simply implement the UTF-16 variant of `main()`: `wmain()`. To make that work, we need to link with -municode. The command-line parameters are passed to `wmain()` encoded in UTF-16, as desired, and this method also works with GCC, and also with Visual C++ after adjusting the MSVC linker flags to force it to use `wmain()`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-20 00:05:59 +03:00
BASIC_LDFLAGS = -IGNORE:4217 -IGNORE:4049 -NOLOGO -ENTRY:wmainCRTStartup -SUBSYSTEM:CONSOLE
msvc: support building Git using MS Visual C++ With this patch, Git can be built using the Microsoft toolchain, via: make MSVC=1 [DEBUG=1] Third party libraries are built from source using the open source "vcpkg" tool set. See https://github.com/Microsoft/vcpkg On a first build, the vcpkg tools and the third party libraries are automatically downloaded and built. DLLs for the third party libraries are copied to the top-level (and t/helper) directory to facilitate debugging. See compat/vcbuild/README. A series of .bat files are invoked by the Makefile to find the location of the installed version of Visual Studio and the associated compiler tools (essentially replicating the environment setup performed by a "Developer Command Prompt"). This should find the most recent VS2015 or VS2017 installation. Output from these scripts are used by the Makefile to define compiler and linker pathnames and -I and -L arguments. The build produces .pdb files for both debug and release builds. Note: This commit was squashed from an organic series of commits developed between 2016 and 2018 in Git for Windows' `master` branch. This combined commit eliminates the obsolete commits related to fetching NuGet packages for third party libraries. It is difficult to use NuGet packages for C/C++ sources because they may be built by earlier versions of the MSVC compiler and have CRT version and linking issues. Additionally, the C/C++ NuGet packages that we were using tended to not be updated concurrently with the sources. And in the case of cURL and OpenSSL, this could expose us to security issues. Helped-by: Yue Lin Ho <b8732003@student.nsysu.edu.tw> Helped-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-25 17:49:39 +03:00
# invalidcontinue.obj allows Git's source code to close the same file
# handle twice, or to access the osfhandle of an already-closed stdout
# See https://msdn.microsoft.com/en-us/library/ms235330.aspx
EXTLIBS = user32.lib advapi32.lib shell32.lib wininet.lib ws2_32.lib invalidcontinue.obj kernel32.lib ntdll.lib
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
PTHREAD_LIBS =
lib =
msvc: support building Git using MS Visual C++ With this patch, Git can be built using the Microsoft toolchain, via: make MSVC=1 [DEBUG=1] Third party libraries are built from source using the open source "vcpkg" tool set. See https://github.com/Microsoft/vcpkg On a first build, the vcpkg tools and the third party libraries are automatically downloaded and built. DLLs for the third party libraries are copied to the top-level (and t/helper) directory to facilitate debugging. See compat/vcbuild/README. A series of .bat files are invoked by the Makefile to find the location of the installed version of Visual Studio and the associated compiler tools (essentially replicating the environment setup performed by a "Developer Command Prompt"). This should find the most recent VS2015 or VS2017 installation. Output from these scripts are used by the Makefile to define compiler and linker pathnames and -I and -L arguments. The build produces .pdb files for both debug and release builds. Note: This commit was squashed from an organic series of commits developed between 2016 and 2018 in Git for Windows' `master` branch. This combined commit eliminates the obsolete commits related to fetching NuGet packages for third party libraries. It is difficult to use NuGet packages for C/C++ sources because they may be built by earlier versions of the MSVC compiler and have CRT version and linking issues. Additionally, the C/C++ NuGet packages that we were using tended to not be updated concurrently with the sources. And in the case of cURL and OpenSSL, this could expose us to security issues. Helped-by: Yue Lin Ho <b8732003@student.nsysu.edu.tw> Helped-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-25 17:49:39 +03:00
BASIC_CFLAGS += $(vcpkg_inc) $(sdk_includes) $(msvc_includes)
ifndef DEBUG
BASIC_CFLAGS += $(vcpkg_rel_lib)
else
BASIC_CFLAGS += $(vcpkg_dbg_lib)
endif
BASIC_CFLAGS += $(sdk_libs) $(msvc_libs)
msvc: add a compile-time flag to allow detailed heap debugging MS Visual C comes with a few neat features we can use to analyze the heap consumption (i.e. leaks, max memory, etc). With this patch, we introduce support via the build-time flag `USE_MSVC_CRTDBG`. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-25 17:49:40 +03:00
ifneq ($(USE_MSVC_CRTDBG),)
# Optionally enable memory leak reporting.
BASIC_CFLAGS += -DUSE_MSVC_CRTDBG
endif
msvc: support building Git using MS Visual C++ With this patch, Git can be built using the Microsoft toolchain, via: make MSVC=1 [DEBUG=1] Third party libraries are built from source using the open source "vcpkg" tool set. See https://github.com/Microsoft/vcpkg On a first build, the vcpkg tools and the third party libraries are automatically downloaded and built. DLLs for the third party libraries are copied to the top-level (and t/helper) directory to facilitate debugging. See compat/vcbuild/README. A series of .bat files are invoked by the Makefile to find the location of the installed version of Visual Studio and the associated compiler tools (essentially replicating the environment setup performed by a "Developer Command Prompt"). This should find the most recent VS2015 or VS2017 installation. Output from these scripts are used by the Makefile to define compiler and linker pathnames and -I and -L arguments. The build produces .pdb files for both debug and release builds. Note: This commit was squashed from an organic series of commits developed between 2016 and 2018 in Git for Windows' `master` branch. This combined commit eliminates the obsolete commits related to fetching NuGet packages for third party libraries. It is difficult to use NuGet packages for C/C++ sources because they may be built by earlier versions of the MSVC compiler and have CRT version and linking issues. Additionally, the C/C++ NuGet packages that we were using tended to not be updated concurrently with the sources. And in the case of cURL and OpenSSL, this could expose us to security issues. Helped-by: Yue Lin Ho <b8732003@student.nsysu.edu.tw> Helped-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-25 17:49:39 +03:00
# Always give "-Zi" to the compiler and "-debug" to linker (even in
# release mode) to force a PDB to be generated (like RelWithDebInfo).
BASIC_CFLAGS += -Zi
BASIC_LDFLAGS += -debug -Zf
ifdef NO_SAFESEH
LDFLAGS += -SAFESEH:NO
endif
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
ifndef DEBUG
msvc: support building Git using MS Visual C++ With this patch, Git can be built using the Microsoft toolchain, via: make MSVC=1 [DEBUG=1] Third party libraries are built from source using the open source "vcpkg" tool set. See https://github.com/Microsoft/vcpkg On a first build, the vcpkg tools and the third party libraries are automatically downloaded and built. DLLs for the third party libraries are copied to the top-level (and t/helper) directory to facilitate debugging. See compat/vcbuild/README. A series of .bat files are invoked by the Makefile to find the location of the installed version of Visual Studio and the associated compiler tools (essentially replicating the environment setup performed by a "Developer Command Prompt"). This should find the most recent VS2015 or VS2017 installation. Output from these scripts are used by the Makefile to define compiler and linker pathnames and -I and -L arguments. The build produces .pdb files for both debug and release builds. Note: This commit was squashed from an organic series of commits developed between 2016 and 2018 in Git for Windows' `master` branch. This combined commit eliminates the obsolete commits related to fetching NuGet packages for third party libraries. It is difficult to use NuGet packages for C/C++ sources because they may be built by earlier versions of the MSVC compiler and have CRT version and linking issues. Additionally, the C/C++ NuGet packages that we were using tended to not be updated concurrently with the sources. And in the case of cURL and OpenSSL, this could expose us to security issues. Helped-by: Yue Lin Ho <b8732003@student.nsysu.edu.tw> Helped-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-25 17:49:39 +03:00
BASIC_CFLAGS += -GL -Gy -O2 -Oy- -MD -DNDEBUG
BASIC_LDFLAGS += -release -LTCG /OPT:REF /OPT:ICF /INCREMENTAL:NO /DEBUGTYPE:CV,FIXUP
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
AR += -LTCG
else
msvc: support building Git using MS Visual C++ With this patch, Git can be built using the Microsoft toolchain, via: make MSVC=1 [DEBUG=1] Third party libraries are built from source using the open source "vcpkg" tool set. See https://github.com/Microsoft/vcpkg On a first build, the vcpkg tools and the third party libraries are automatically downloaded and built. DLLs for the third party libraries are copied to the top-level (and t/helper) directory to facilitate debugging. See compat/vcbuild/README. A series of .bat files are invoked by the Makefile to find the location of the installed version of Visual Studio and the associated compiler tools (essentially replicating the environment setup performed by a "Developer Command Prompt"). This should find the most recent VS2015 or VS2017 installation. Output from these scripts are used by the Makefile to define compiler and linker pathnames and -I and -L arguments. The build produces .pdb files for both debug and release builds. Note: This commit was squashed from an organic series of commits developed between 2016 and 2018 in Git for Windows' `master` branch. This combined commit eliminates the obsolete commits related to fetching NuGet packages for third party libraries. It is difficult to use NuGet packages for C/C++ sources because they may be built by earlier versions of the MSVC compiler and have CRT version and linking issues. Additionally, the C/C++ NuGet packages that we were using tended to not be updated concurrently with the sources. And in the case of cURL and OpenSSL, this could expose us to security issues. Helped-by: Yue Lin Ho <b8732003@student.nsysu.edu.tw> Helped-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-25 17:49:39 +03:00
BASIC_CFLAGS += -MDd -DDEBUG -D_DEBUG
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
endif
X = .exe
msvc: fix dependencies of compat/msvc.c The file compat/msvc.c includes compat/mingw.c, which means that we have to recompile compat/msvc.o if compat/mingw.c changes. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-20 00:06:00 +03:00
compat/msvc.o: compat/msvc.c compat/mingw.c GIT-CFLAGS
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
endif
ifeq ($(uname_S),Interix)
NO_INITGROUPS = YesPlease
NO_IPV6 = YesPlease
NO_MEMMEM = YesPlease
NO_MKDTEMP = YesPlease
NO_STRTOUMAX = YesPlease
NO_NSEC = YesPlease
ifeq ($(uname_R),3.5)
NO_INET_NTOP = YesPlease
NO_INET_PTON = YesPlease
NO_SOCKADDR_STORAGE = YesPlease
endif
ifeq ($(uname_R),5.2)
NO_INET_NTOP = YesPlease
NO_INET_PTON = YesPlease
NO_SOCKADDR_STORAGE = YesPlease
endif
endif
ifeq ($(uname_S),Minix)
NO_IPV6 = YesPlease
NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
NO_NSEC = YesPlease
NEEDS_LIBGEN =
NEEDS_CRYPTO_WITH_SSL = YesPlease
NEEDS_RESOLV =
NO_HSTRERROR = YesPlease
NO_MMAP = YesPlease
NO_CURL =
NO_EXPAT =
endif
ifeq ($(uname_S),NONSTOP_KERNEL)
# Needs some C99 features, "inline" is just one of them.
# INLINE='' would just replace one set of warnings with another and
# still not compile in c89 mode, due to non-const array initializations.
CC = cc -c99
config.mak.uname: support for modern HPE NonStop config. A number of configuration options are not automatically detected by configure mechanisms, including the location of Perl and Python. There was a problem at a specific set of operating system versions that caused getopt to have compile errors. Account for this by providing emulation defines for those versions. Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-04 00:03:49 +03:00
# Build down-rev compatible objects that don't use our new getopt_long.
ifeq ($(uname_R).$(uname_V),J06.21)
CC += -WRVU=J06.20
endif
ifeq ($(uname_R).$(uname_V),L17.02)
CC += -WRVU=L16.05
endif
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
# Disable all optimization, seems to result in bad code, with -O or -O2
# or even -O1 (default), /usr/local/libexec/git-core/git-pack-objects
# abends on "git push". Needs more investigation.
config.mak.uname: support for modern HPE NonStop config. A number of configuration options are not automatically detected by configure mechanisms, including the location of Perl and Python. There was a problem at a specific set of operating system versions that caused getopt to have compile errors. Account for this by providing emulation defines for those versions. Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-04 00:03:49 +03:00
CFLAGS = -g -O0 -Winline
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
# We'd want it to be here.
prefix = /usr/local
config.mak.uname: support for modern HPE NonStop config. A number of configuration options are not automatically detected by configure mechanisms, including the location of Perl and Python. There was a problem at a specific set of operating system versions that caused getopt to have compile errors. Account for this by providing emulation defines for those versions. Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-04 00:03:49 +03:00
# perl and python must be in /usr/bin on NonStop - supplied by HPE
# with operating system in that managed directory.
PERL_PATH = /usr/bin/perl
PYTHON_PATH = /usr/bin/python
# The current /usr/coreutils/rm at lowest support level does not work
# with the git test structure. Long paths as in
# 'trash directory...' cause rm to terminate prematurely without fully
# removing the directory at OS releases J06.21 and L17.02.
# Default to the older rm until those two releases are deprecated.
RM = /bin/rm -f
NEEDS_CRYPTO_WITH_SSL = YesPlease
HAVE_DEV_TTY = YesPlease
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
HAVE_LIBCHARSET_H = YesPlease
HAVE_STRINGS_H = YesPlease
NEEDS_LIBICONV = YesPlease
NEEDS_LIBINTL_BEFORE_LIBICONV = YesPlease
NO_SYS_SELECT_H = UnfortunatelyYes
NO_D_TYPE_IN_DIRENT = YesPlease
config.mak.uname: support for modern HPE NonStop config. A number of configuration options are not automatically detected by configure mechanisms, including the location of Perl and Python. There was a problem at a specific set of operating system versions that caused getopt to have compile errors. Account for this by providing emulation defines for those versions. Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-04 00:03:49 +03:00
NO_GETTEXT = YesPlease
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
NO_HSTRERROR = YesPlease
NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
NO_STRLCPY = YesPlease
NO_SETENV = YesPlease
NO_UNSETENV = YesPlease
NO_MKDTEMP = YesPlease
# Currently libiconv-1.9.1.
OLD_ICONV = UnfortunatelyYes
config.mak.uname: support for modern HPE NonStop config. A number of configuration options are not automatically detected by configure mechanisms, including the location of Perl and Python. There was a problem at a specific set of operating system versions that caused getopt to have compile errors. Account for this by providing emulation defines for those versions. Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-04 00:03:49 +03:00
NO_REGEX = NeedsStartEnd
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
NO_PTHREADS = UnfortunatelyYes
config.mak.uname: add FREAD_READS_DIRECTORIES for NonStop platform The NonStop platform needs this configuration item specified as UnfortunatelyYes so that config directory files are correctly processed. Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-10 03:20:16 +03:00
FREAD_READS_DIRECTORIES = UnfortunatelyYes
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
# Not detected (nor checked for) by './configure'.
# We don't have SA_RESTART on NonStop, unfortunalety.
COMPAT_CFLAGS += -DSA_RESTART=0
# Apparently needed in compat/fnmatch/fnmatch.c.
COMPAT_CFLAGS += -DHAVE_STRING_H=1
NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
NO_NSEC = YesPlease
NO_PREAD = YesPlease
NO_MMAP = YesPlease
NO_POLL = YesPlease
NO_INTPTR_T = UnfortunatelyYes
wrapper: add a helper to generate numbers from a CSPRNG There are many situations in which having access to a cryptographically secure pseudorandom number generator (CSPRNG) is helpful. In the future, we'll encounter one of these when dealing with temporary files. To make this possible, let's add a function which reads from a system CSPRNG and returns some bytes. We know that all systems will have such an interface. A CSPRNG is required for a secure TLS or SSH implementation and a Git implementation which provided neither would be of little practical use. In addition, POSIX is set to standardize getentropy(2) in the next version, so in the (potentially distant) future we can rely on that. For systems which lack one of the other interfaces, we provide the ability to use OpenSSL's CSPRNG. OpenSSL is highly portable and functions on practically every known OS, and we know it will have access to some source of cryptographically secure randomness. We also provide support for the arc4random in libbsd for folks who would prefer to use that. Because this is a security sensitive interface, we take some precautions. We either succeed by filling the buffer completely as we requested, or we fail. We don't return partial data because the caller will almost never find that to be a useful behavior. Specify a makefile knob which users can use to specify one or more suitable CSPRNGs, and turn the multiple string options into a set of defines, since we cannot match on strings in the preprocessor. We allow multiple options to make the job of handling this in autoconf easier. The order of options is important here. On systems with arc4random, which is most of the BSDs, we use that, since, except on MirBSD and macOS, it uses ChaCha20, which is extremely fast, and sits entirely in userspace, avoiding a system call. We then prefer getrandom over getentropy, because the former has been available longer on Linux, and then OpenSSL. Finally, if none of those are available, we use /dev/urandom, because most Unix-like operating systems provide that API. We prefer options that don't involve device files when possible because those work in some restricted environments where device files may not be available. Set the configuration variables appropriately for Linux and the BSDs, including macOS, as well as Windows and NonStop. We specifically only consider versions which receive publicly available security support here. For the same reason, we don't specify getrandom(2) on Linux, because CentOS 7 doesn't support it in glibc (although its kernel does) and we don't want to resort to making syscalls. Finally, add a test helper to allow this to be tested by hand and in tests. We don't add any tests, since invoking the CSPRNG is not likely to produce interesting, reproducible results. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-18 00:56:16 +03:00
CSPRNG_METHOD = openssl
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
SANE_TOOL_PATH = /usr/coreutils/bin:/usr/local/bin
config.mak.uname: move location of bash on NonStop to CoreUtils The default bash is now officially in /usr/coreutils/bin instead of in /usr/local/bin. This version of bash is more stable and recommended for all use as of the J06.22 and L18.02 operating system revision levels. This new version provides more stability of test results. Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-09 20:26:11 +03:00
SHELL_PATH = /usr/coreutils/bin/bash
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
endif
Makefile: restrict -Wpedantic and -Wno-pedantic-ms-format better 6a8cbc41ba (developer: enable pedantic by default, 2021-09-03) enables pedantic mode in as many compilers as possible to help gather feedback on future tightening, so lets do so. -Wpedantic is missing in some really old gcc 4 versions so lets restrict it to gcc5 and clang4 (it does work in clang3 AFAIK, but it will be unlikely that a developer will use such an old compiler anyway). MinGW gcc is the only one which has -Wno-pedantic-ms-format, and while that is available also in older compilers, the Windows SDK provides gcc10 so lets aim for that. Note that in order to target the flag to only Windows, additional changes were needed in config.mak.uname to propagate the OS detection which also did some minor refactoring, but which is functionaly equivalent. Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-29 06:19:40 +03:00
ifeq ($(uname_S),MINGW)
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
pathsep = ;
mingw: activate alloca Both MSVC and MINGW have alloca(3) definitions in malloc.h, so by moving win32-compat alloca.h from compat/vcbuild/include/ to compat/win32/ , which is included by both MSVC and MINGW CFLAGS, we can make alloca() work on both those Windows environments. In MINGW, malloc.h has explicit check for GNUC and if it is so, defines alloca to __builtin_alloca, so it looks like we don't need to add any code to here-shipped alloca.h to get optimum performance. Compile-tested on Windows in MSysGit. Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru> Acked-by: Erik Faye-Lund <kusmabite@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-09 16:48:27 +04:00
HAVE_ALLOCA_H = YesPlease
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
NO_PREAD = YesPlease
NEEDS_CRYPTO_WITH_SSL = YesPlease
NO_LIBGEN_H = YesPlease
NO_POLL = YesPlease
NO_SYMLINK_HEAD = YesPlease
NO_UNIX_SOCKETS = YesPlease
NO_SETENV = YesPlease
NO_STRCASESTR = YesPlease
NO_STRLCPY = YesPlease
NO_MEMMEM = YesPlease
NEEDS_LIBICONV = YesPlease
NO_STRTOUMAX = YesPlease
NO_MKDTEMP = YesPlease
NO_SVN_TESTS = YesPlease
compat/fsmonitor/fsm-listen-win32: stub in backend for Windows Stub in empty filesystem listener backend for fsmonitor--daemon on Windows. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-25 21:02:51 +03:00
# The builtin FSMonitor requires Named Pipes and Threads on Windows.
# These are always available, so we do not have to conditionally
# support it.
FSMONITOR_DAEMON_BACKEND = win32
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
RUNTIME_PREFIX = YesPlease
mingw/msvc: use the new-style RUNTIME_PREFIX helper This change also allows us to stop overriding argv[0] with the absolute path of the executable, allowing us to preserve e.g. the case of the executable's file name. This fixes https://github.com/git-for-windows/git/issues/1496 partially. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-10 18:05:46 +03:00
HAVE_WPGMPTR = YesWeDo
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
simple-ipc: add win32 implementation Create Windows implementation of "simple-ipc" using named pipes. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-16 00:08:23 +03:00
USE_WIN32_IPC = YesPlease
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
USE_WIN32_MMAP = YesPlease
packed_ref_cache: keep the `packed-refs` file mmapped if possible Keep a copy of the `packed-refs` file contents in memory for as long as a `packed_ref_cache` object is in use: * If the system allows it, keep the `packed-refs` file mmapped. * If not (either because the system doesn't support `mmap()` at all, or because a file that is currently mmapped cannot be replaced via `rename()`), then make a copy of the file's contents in heap-allocated space, and keep that around instead. We base the choice of behavior on a new build-time switch, `MMAP_PREVENTS_DELETE`. By default, this switch is set for Windows variants. After this commit, `MMAP_NONE` and `MMAP_TEMPORARY` are still handled identically. But the next commit will introduce a difference. This whole change is still pointless, because we only read the `packed-refs` file contents immediately after instantiating the `packed_ref_cache`. But that will soon change. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-25 11:00:10 +03:00
MMAP_PREVENTS_DELETE = UnfortunatelyYes
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
USE_NED_ALLOCATOR = YesPlease
UNRELIABLE_FSTAT = UnfortunatelyYes
OBJECT_CREATION_USES_RENAMES = UnfortunatelyNeedsTo
NO_REGEX = YesPlease
NO_PYTHON = YesPlease
ETAGS_TARGET = ETAGS
NO_POSIX_GOODIES = UnfortunatelyYes
Set the default help format to html for msys builds. This resolves issue #19 by setting the compiled default to html in msys builds following the changes introduced by commit 1cc8af0 "help: use HTML as the default help format on Windows" Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2012-06-21 15:24:14 +04:00
DEFAULT_HELP_FORMAT = html
tr2: make process info collection platform-generic To pave the way for non-Windows platforms to define trace2_collect_process_info(), reorganize the stub-or-definition schema to something which doesn't directly reference Windows. Platforms which want to collect parent process information in the future should: 1. Add an implementation to compat/ (e.g. compat/somearch/procinfo.c) 2. Add that object to COMPAT_OBJS to config.mak.uname (e.g. COMPAT_OBJS += compat/somearch/procinfo.o) 3. Define HAVE_PLATFORM_PROCINFO in config.mak.uname In the Windows case, this definition lives in compat/win32/trace2_win32_process_info.c, which is already conditionally added to COMPAT_OBJS; so let's add HAVE_PLATFORM_PROCINFO to hint to the build that compat/stub/procinfo.c should not be used. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-22 04:27:06 +03:00
HAVE_PLATFORM_PROCINFO = YesPlease
wrapper: add a helper to generate numbers from a CSPRNG There are many situations in which having access to a cryptographically secure pseudorandom number generator (CSPRNG) is helpful. In the future, we'll encounter one of these when dealing with temporary files. To make this possible, let's add a function which reads from a system CSPRNG and returns some bytes. We know that all systems will have such an interface. A CSPRNG is required for a secure TLS or SSH implementation and a Git implementation which provided neither would be of little practical use. In addition, POSIX is set to standardize getentropy(2) in the next version, so in the (potentially distant) future we can rely on that. For systems which lack one of the other interfaces, we provide the ability to use OpenSSL's CSPRNG. OpenSSL is highly portable and functions on practically every known OS, and we know it will have access to some source of cryptographically secure randomness. We also provide support for the arc4random in libbsd for folks who would prefer to use that. Because this is a security sensitive interface, we take some precautions. We either succeed by filling the buffer completely as we requested, or we fail. We don't return partial data because the caller will almost never find that to be a useful behavior. Specify a makefile knob which users can use to specify one or more suitable CSPRNGs, and turn the multiple string options into a set of defines, since we cannot match on strings in the preprocessor. We allow multiple options to make the job of handling this in autoconf easier. The order of options is important here. On systems with arc4random, which is most of the BSDs, we use that, since, except on MirBSD and macOS, it uses ChaCha20, which is extremely fast, and sits entirely in userspace, avoiding a system call. We then prefer getrandom over getentropy, because the former has been available longer on Linux, and then OpenSSL. Finally, if none of those are available, we use /dev/urandom, because most Unix-like operating systems provide that API. We prefer options that don't involve device files when possible because those work in some restricted environments where device files may not be available. Set the configuration variables appropriately for Linux and the BSDs, including macOS, as well as Windows and NonStop. We specifically only consider versions which receive publicly available security support here. For the same reason, we don't specify getrandom(2) on Linux, because CentOS 7 doesn't support it in glibc (although its kernel does) and we don't want to resort to making syscalls. Finally, add a test helper to allow this to be tested by hand and in tests. We don't add any tests, since invoking the CSPRNG is not likely to produce interesting, reproducible results. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-18 00:56:16 +03:00
CSPRNG_METHOD = rtlgenrandom
mingw: replace mingw_startup() hack Git for Windows has special code to retrieve the command-line parameters (and even the environment) in UTF-16 encoding, so that they can be converted to UTF-8. This is necessary because Git for Windows wants to use UTF-8 encoded strings throughout its code, and the main() function does not get the parameters in that encoding. To do that, we used the __wgetmainargs() function, which is not even a Win32 API function, but provided by the MINGW "runtime" instead. Obviously, this method would not work with any compiler other than GCC, and in preparation for compiling with Visual C++, we would like to avoid precisely that. Lucky us, there is a much more elegant way: we can simply implement the UTF-16 variant of `main()`: `wmain()`. To make that work, we need to link with -municode. The command-line parameters are passed to `wmain()` encoded in UTF-16, as desired, and this method also works with GCC, and also with Visual C++ after adjusting the MSVC linker flags to force it to use `wmain()`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-20 00:05:59 +03:00
BASIC_LDFLAGS += -municode
config.mak.uname: supporting 64-bit MSys2 This just makes things compile, the test suite needs extra tender loving care in addition to this change. We will address these issues in later commits. While at it, also allow building MSys2 Git (i.e. a Git that uses MSys2's POSIX emulation layer). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13 16:31:01 +03:00
COMPAT_CFLAGS += -DNOGDI -Icompat -Icompat/win32
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
COMPAT_CFLAGS += -DSTRIP_EXTENSION=\".exe\"
COMPAT_OBJS += compat/mingw.o compat/winansi.o \
trace2: collect Windows-specific process information Add platform-specific interface to log information about the current process. On Windows, this interface is used to indicate whether the git process is running under a debugger and list names of the process ancestors. Information for other platforms is left for a future effort. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-23 01:25:02 +03:00
compat/win32/trace2_win32_process_info.o \
core.fsyncmethod: add writeout-only mode This commit introduces the `core.fsyncMethod` configuration knob, which can currently be set to `fsync` or `writeout-only`. The new writeout-only mode attempts to tell the operating system to flush its in-memory page cache to the storage hardware without issuing a CACHE_FLUSH command to the storage controller. Writeout-only fsync is significantly faster than a vanilla fsync on common hardware, since data is written to a disk-side cache rather than all the way to a durable medium. Later changes in this patch series will take advantage of this primitive to implement batching of hardware flushes. When git_fsync is called with FSYNC_WRITEOUT_ONLY, it may fail and the caller is expected to do an ordinary fsync as needed. On Apple platforms, the fsync system call does not issue a CACHE_FLUSH directive to the storage controller. This change updates fsync to do fcntl(F_FULLFSYNC) to make fsync actually durable. We maintain parity with existing behavior on Apple platforms by setting the default value of the new core.fsyncMethod option. Signed-off-by: Neeraj Singh <neerajsi@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-11 01:43:20 +03:00
compat/win32/flush.o \
git clone <url> C:\cygwin\home\USER\repo' is working (again) A regression for cygwin users was introduced with commit 05b458c, "real_path: resolve symlinks by hand". In the the commit message we read: The current implementation of real_path uses chdir() in order to resolve symlinks. Unfortunately this isn't thread-safe as chdir() affects a process as a whole... The old (and non-thread-save) OS calls chdir()/pwd() had been replaced by a string operation. The cygwin layer "knows" that "C:\cygwin" is an absolute path, but the new string operation does not. "git clone <url> C:\cygwin\home\USER\repo" fails like this: fatal: Invalid path '/home/USER/repo/C:\cygwin\home\USER\repo' The solution is to implement has_dos_drive_prefix(), skip_dos_drive_prefix() is_dir_sep(), offset_1st_component() and convert_slashes() for cygwin in the same way as it is done in 'Git for Windows' in compat/mingw.[ch] Extract the needed code into compat/win32/path-utils.[ch] and use it for cygwin as well. Reported-by: Steven Penny <svnpenn@gmail.com> Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-15 07:33:30 +03:00
compat/win32/path-utils.o \
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
compat/win32/pthread.o compat/win32/syslog.o \
compat/win32/dirent.o
Sync with 2.18.2 * maint-2.18: (33 commits) Git 2.18.2 Git 2.17.3 Git 2.16.6 test-drop-caches: use `has_dos_drive_prefix()` Git 2.15.4 Git 2.14.6 mingw: handle `subst`-ed "DOS drives" mingw: refuse to access paths with trailing spaces or periods mingw: refuse to access paths with illegal characters unpack-trees: let merged_entry() pass through do_add_entry()'s errors quote-stress-test: offer to test quoting arguments for MSYS2 sh t6130/t9350: prepare for stringent Win32 path validation quote-stress-test: allow skipping some trials quote-stress-test: accept arguments to test via the command-line tests: add a helper to stress test argument quoting mingw: fix quoting of arguments Disallow dubiously-nested submodule git directories protect_ntfs: turn on NTFS protection by default path: also guard `.gitmodules` against NTFS Alternate Data Streams is_ntfs_dotgit(): speed it up ...
2019-12-05 00:27:04 +03:00
BASIC_CFLAGS += -DWIN32
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
EXTLIBS += -lws2_32
Provide a Windows version resource for the git executables. Embeds the git version and description into the git executable thus implementing the request in issue #5. Acked-by: Heiko Voigt <hvoigt@hvoigt.net> Acked-by: Sebastian Schuberth <sschuberth@gmail.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2012-05-24 03:56:24 +04:00
GITLIBS += git.res
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
PTHREAD_LIBS =
Provide a Windows version resource for the git executables. Embeds the git version and description into the git executable thus implementing the request in issue #5. Acked-by: Heiko Voigt <hvoigt@hvoigt.net> Acked-by: Sebastian Schuberth <sschuberth@gmail.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2012-05-24 03:56:24 +04:00
RC = windres -O coff
convert: The native line-ending is \r\n on MinGW If you try this: 1. Install Git for Windows (from the msysgit project) 2. Put [core] autocrlf = false eol = native in your .gitconfig. 3. Clone a project with *.txt text in its .gitattributes. Then with current git, any text files checked out have LF line endings, instead of the expected CRLF. Cc: Johannes Schindelin <johannes.schindelin@gmx.de> Cc: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-04 12:25:09 +04:00
NATIVE_CRLF = YesPlease
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
X = .exe
ifneq (,$(wildcard ../THIS_IS_MSYSGIT))
htmldir = doc/git/html/
prefix =
INSTALL = /bin/install
EXTLIBS += /mingw/lib/libz.a
INTERNAL_QSORT = YesPlease
HAVE_LIBCHARSET_H = YesPlease
Define NO_GETTEXT for Git for Windows The dreaded "your vnsprintf is broken (returned -1)" error is back. At least with the libintl version we have. So for the moment, just work around the issue by _not_ using gettext. Ah, I wish that my attempt at implementing a custom strbuf_vaddf() would not have been brushed aside so rashly. Oh well. Time saved on maintaining that thing, I guess (although more time went into working around coping with existing implementations). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2012-01-06 02:41:41 +04:00
NO_GETTEXT = YesPlease
mingw: fix a typo in the msysGit-specific section The msysGit project (i.e. Git for Windows 1.x' SDK) is safely dead for *years* already. This is probably the reason why nobody caught this typo until Carlo Arenas spotted a copy-edited version of it nearby. It is probably about time to rip out the remainders of msysGit/MSys1 support, but that can safely wait a bit longer, and we can at least fix the typo for now. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-20 00:05:56 +03:00
COMPAT_CFLAGS += -D__USE_MINGW_ACCESS
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
else
mingw: allow building with an MSYS2 runtime v3.x Recently the Git for Windows project started the upgrade process to a MSYS2 runtime version based on Cygwin v3.x. This has the very notable consequence that `$(uname -r)` no longer reports a version starting with "2", but a version with "3". That breaks our build, as df5218b4c30b (config.mak.uname: support MSys2, 2016-01-13) simply did not expect the version reported by `uname -r` to depend on the underlying Cygwin version: it expected the reported version to match the "2" in "MSYS2". So let's invert that test case to test for *anything else* than a version starting with "1" (for MSys). That should safeguard us for the future, even if Cygwin ends up releasing versionsl like 314.272.65536. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-08 18:51:19 +03:00
ifneq ($(shell expr "$(uname_R)" : '1\.'),2)
config.mak.uname: support MSys2 For a long time, Git for Windows lagged behind Git's 2.x releases because the Git for Windows developers wanted to let that big jump coincide with a well-needed jump away from MSys to MSys2. To understand why this is such a big issue, it needs to be noted that many parts of Git are not written in portable C, but instead Git relies on a POSIX shell and Perl to be available. To support the scripts, Git for Windows has to ship a minimal POSIX emulation layer with Bash and Perl thrown in, and when the Git for Windows effort started in August 2007, this developer settled on using MSys, a stripped down version of Cygwin. Consequently, the original name of the project was "msysGit" (which, sadly, caused a *lot* of confusion because few Windows users know about MSys, and even less care). To compile the C code of Git for Windows, MSys was used, too: it sports two versions of the GNU C Compiler: one that links implicitly to the POSIX emulation layer, and another one that targets the plain Win32 API (with a few convenience functions thrown in). Git for Windows' executables are built using the latter, and therefore they are really just Win32 programs. To discern executables requiring the POSIX emulation layer from the ones that do not, the latter are called MinGW (Minimal GNU for Windows) when the former are called MSys executables. This reliance on MSys incurred challenges, too, though: some of our changes to the MSys runtime -- necessary to support Git for Windows better -- were not accepted upstream, so we had to maintain our own fork. Also, the MSys runtime was not developed further to support e.g. UTF-8 or 64-bit, and apart from lacking a package management system until much later (when mingw-get was introduced), many packages provided by the MSys/MinGW project lag behind the respective source code versions, in particular Bash and OpenSSL. For a while, the Git for Windows project tried to remedy the situation by trying to build newer versions of those packages, but the situation quickly became untenable, especially with problems like the Heartbleed bug requiring swift action that has nothing to do with developing Git for Windows further. Happily, in the meantime the MSys2 project (https://msys2.github.io/) emerged, and was chosen to be the base of the Git for Windows 2.x. Just like MSys, MSys2 is a stripped down version of Cygwin, but it is actively kept up-to-date with Cygwin's source code. Thereby, it already supports Unicode internally, and it also offers the 64-bit support that we yearned for since the beginning of the Git for Windows project. MSys2 also ported the Pacman package management system from Arch Linux and uses it heavily. This brings the same convenience to which Linux users are used to from `yum` or `apt-get`, and to which MacOSX users are used to from Homebrew or MacPorts, or BSD users from the Ports system, to MSys2: a simple `pacman -Syu` will update all installed packages to the newest versions currently available. MSys2 is also *very* active, typically providing package updates multiple times per week. It still required a two-month effort to bring everything to a state where Git's test suite passes, many more months until the first official Git for Windows 2.x was released, and a couple of patches still await their submission to the respective upstream projects. Yet without MSys2, the modernization of Git for Windows would simply not have happened. This commit lays the ground work to supporting MSys2-based Git builds. Assisted-by: Waldek Maleska <weakcamel@users.github.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13 16:30:53 +03:00
# MSys2
config.mak.uname: supporting 64-bit MSys2 This just makes things compile, the test suite needs extra tender loving care in addition to this change. We will address these issues in later commits. While at it, also allow building MSys2 Git (i.e. a Git that uses MSys2's POSIX emulation layer). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13 16:31:01 +03:00
prefix = /usr/
mingw: enable DEP and ASLR Enable DEP (Data Execution Prevention) and ASLR (Address Space Layout Randomization) support. This applies to both 32bit and 64bit builds and makes it substantially harder to exploit security holes in Git by offering a much more unpredictable attack surface. ASLR interferes with GDB's ability to set breakpoints. A similar issue holds true when compiling with -O2 (in which case single-stepping is messed up because GDB cannot map the code back to the original source code properly). Therefore we simply enable ASLR only when an optimization flag is present in the CFLAGS, using it as an indicator that the developer does not want to debug in GDB anyway. Signed-off-by: İsmail Dönmez <ismail@i10z.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-08 14:30:59 +03:00
# Enable DEP
BASIC_LDFLAGS += -Wl,--nxcompat
# Enable ASLR (unless debugging)
ifneq (,$(findstring -O,$(filter-out -O0 -Og,$(CFLAGS))))
BASIC_LDFLAGS += -Wl,--dynamicbase
endif
config.mak.uname: supporting 64-bit MSys2 This just makes things compile, the test suite needs extra tender loving care in addition to this change. We will address these issues in later commits. While at it, also allow building MSys2 Git (i.e. a Git that uses MSys2's POSIX emulation layer). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13 16:31:01 +03:00
ifeq (MINGW32,$(MSYSTEM))
prefix = /mingw32
mingw: use a more canonical method to fix the CPU reporting In `git version --build-options`, we report also the CPU, but in Git for Windows we actually cross-compile the 32-bit version in a 64-bit Git for Windows, so we cannot rely on the auto-detected value. In 3815f64b0dd9 (mingw: fix CPU reporting in `git version --build-options`, 2019-02-07), we fixed this by a Windows-only workaround, making use of magic pre-processor constants, which works in GCC, but most likely not all C compilers. As pointed out by Eric Sunshine, there is a better way, anyway: to set the Makefile variable HOST_CPU explicitly for cross-compiled Git. So let's do that! This reverts commit 3815f64b0dd983bdbf9242a0547706d5d81cb3e6 partially. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-13 13:19:49 +03:00
HOST_CPU = i686
mingw: do not let ld strip relocations This is the first step for enabling ASLR (Address Space Layout Randomization) support. We want to enable ASLR for better protection against exploiting security holes in Git: it makes it harder to attack software by making code addresses unpredictable. The problem fixed by this commit is that `ld.exe` seems to be stripping relocations which in turn will break ASLR support. We just make sure it's not stripping the main executable entry. Signed-off-by: İsmail Dönmez <ismail@i10z.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-08 14:30:58 +03:00
BASIC_LDFLAGS += -Wl,--pic-executable,-e,_mainCRTStartup
config.mak.uname: supporting 64-bit MSys2 This just makes things compile, the test suite needs extra tender loving care in addition to this change. We will address these issues in later commits. While at it, also allow building MSys2 Git (i.e. a Git that uses MSys2's POSIX emulation layer). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13 16:31:01 +03:00
endif
ifeq (MINGW64,$(MSYSTEM))
prefix = /mingw64
mingw: use a more canonical method to fix the CPU reporting In `git version --build-options`, we report also the CPU, but in Git for Windows we actually cross-compile the 32-bit version in a 64-bit Git for Windows, so we cannot rely on the auto-detected value. In 3815f64b0dd9 (mingw: fix CPU reporting in `git version --build-options`, 2019-02-07), we fixed this by a Windows-only workaround, making use of magic pre-processor constants, which works in GCC, but most likely not all C compilers. As pointed out by Eric Sunshine, there is a better way, anyway: to set the Makefile variable HOST_CPU explicitly for cross-compiled Git. So let's do that! This reverts commit 3815f64b0dd983bdbf9242a0547706d5d81cb3e6 partially. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-13 13:19:49 +03:00
HOST_CPU = x86_64
mingw: do not let ld strip relocations This is the first step for enabling ASLR (Address Space Layout Randomization) support. We want to enable ASLR for better protection against exploiting security holes in Git: it makes it harder to attack software by making code addresses unpredictable. The problem fixed by this commit is that `ld.exe` seems to be stripping relocations which in turn will break ASLR support. We just make sure it's not stripping the main executable entry. Signed-off-by: İsmail Dönmez <ismail@i10z.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-08 14:30:58 +03:00
BASIC_LDFLAGS += -Wl,--pic-executable,-e,mainCRTStartup
config.mak.uname: supporting 64-bit MSys2 This just makes things compile, the test suite needs extra tender loving care in addition to this change. We will address these issues in later commits. While at it, also allow building MSys2 Git (i.e. a Git that uses MSys2's POSIX emulation layer). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13 16:31:01 +03:00
else
COMPAT_CFLAGS += -D_USE_32BIT_TIME_T
BASIC_LDFLAGS += -Wl,--large-address-aware
endif
config.mak.uname: support MSys2 For a long time, Git for Windows lagged behind Git's 2.x releases because the Git for Windows developers wanted to let that big jump coincide with a well-needed jump away from MSys to MSys2. To understand why this is such a big issue, it needs to be noted that many parts of Git are not written in portable C, but instead Git relies on a POSIX shell and Perl to be available. To support the scripts, Git for Windows has to ship a minimal POSIX emulation layer with Bash and Perl thrown in, and when the Git for Windows effort started in August 2007, this developer settled on using MSys, a stripped down version of Cygwin. Consequently, the original name of the project was "msysGit" (which, sadly, caused a *lot* of confusion because few Windows users know about MSys, and even less care). To compile the C code of Git for Windows, MSys was used, too: it sports two versions of the GNU C Compiler: one that links implicitly to the POSIX emulation layer, and another one that targets the plain Win32 API (with a few convenience functions thrown in). Git for Windows' executables are built using the latter, and therefore they are really just Win32 programs. To discern executables requiring the POSIX emulation layer from the ones that do not, the latter are called MinGW (Minimal GNU for Windows) when the former are called MSys executables. This reliance on MSys incurred challenges, too, though: some of our changes to the MSys runtime -- necessary to support Git for Windows better -- were not accepted upstream, so we had to maintain our own fork. Also, the MSys runtime was not developed further to support e.g. UTF-8 or 64-bit, and apart from lacking a package management system until much later (when mingw-get was introduced), many packages provided by the MSys/MinGW project lag behind the respective source code versions, in particular Bash and OpenSSL. For a while, the Git for Windows project tried to remedy the situation by trying to build newer versions of those packages, but the situation quickly became untenable, especially with problems like the Heartbleed bug requiring swift action that has nothing to do with developing Git for Windows further. Happily, in the meantime the MSys2 project (https://msys2.github.io/) emerged, and was chosen to be the base of the Git for Windows 2.x. Just like MSys, MSys2 is a stripped down version of Cygwin, but it is actively kept up-to-date with Cygwin's source code. Thereby, it already supports Unicode internally, and it also offers the 64-bit support that we yearned for since the beginning of the Git for Windows project. MSys2 also ported the Pacman package management system from Arch Linux and uses it heavily. This brings the same convenience to which Linux users are used to from `yum` or `apt-get`, and to which MacOSX users are used to from Homebrew or MacPorts, or BSD users from the Ports system, to MSys2: a simple `pacman -Syu` will update all installed packages to the newest versions currently available. MSys2 is also *very* active, typically providing package updates multiple times per week. It still required a two-month effort to bring everything to a state where Git's test suite passes, many more months until the first official Git for Windows 2.x was released, and a couple of patches still await their submission to the respective upstream projects. Yet without MSys2, the modernization of Git for Windows would simply not have happened. This commit lays the ground work to supporting MSys2-based Git builds. Assisted-by: Waldek Maleska <weakcamel@users.github.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13 16:30:53 +03:00
CC = gcc
mingw: enable stack smashing protector To reduce Git for Windows' attack surface, we started using the Address Space Layout Randomization and Data Execution Prevention features in ce6a158561f9 (mingw: enable DEP and ASLR, 2019-05-08). To remove yet another attack vector, let's make use of gcc's stack smashing protector that helps detect stack buffer overruns early. Rather than using -fstack-protector, we use -fstack-protector-strong because on Windows: The latter appears to strike a better balance between the performance impact and the provided safety. In a non-scientific test (time git log --grep=is -p), best of 5 timings went from 23.009s to 22.997s, i.e. the performance impact was *well* lost in the noise. This fixes https://github.com/git-for-windows/git/issues/501 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-27 12:29:02 +03:00
COMPAT_CFLAGS += -D__USE_MINGW_ANSI_STDIO=0 -DDETECT_MSYS_TTY \
-fstack-protector-strong
mingw: make isatty() recognize MSYS2's pseudo terminals (/dev/pty*) MSYS2 emulates pseudo terminals via named pipes, and isatty() returns 0 for such file descriptors. Therefore, some interactive functionality (such as launching a pager, asking if a failed unlink should be repeated etc.) doesn't work when run in a terminal emulator that uses MSYS2's ptys (such as mintty). However, MSYS2 uses special names for its pty pipes ('msys-*-pty*'), which allows us to distinguish them from normal piped input / output. On startup, check if stdin / stdout / stderr are connected to such pipes using the NtQueryObject API from NTDll.dll. If the names match, adjust the flags in MSVCRT's ioinfo structure accordingly. Signed-off-by: Karsten Blees <blees@dcon.de> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-27 18:16:37 +03:00
EXTLIBS += -lntdll
config.mak.uname: support MSys2 For a long time, Git for Windows lagged behind Git's 2.x releases because the Git for Windows developers wanted to let that big jump coincide with a well-needed jump away from MSys to MSys2. To understand why this is such a big issue, it needs to be noted that many parts of Git are not written in portable C, but instead Git relies on a POSIX shell and Perl to be available. To support the scripts, Git for Windows has to ship a minimal POSIX emulation layer with Bash and Perl thrown in, and when the Git for Windows effort started in August 2007, this developer settled on using MSys, a stripped down version of Cygwin. Consequently, the original name of the project was "msysGit" (which, sadly, caused a *lot* of confusion because few Windows users know about MSys, and even less care). To compile the C code of Git for Windows, MSys was used, too: it sports two versions of the GNU C Compiler: one that links implicitly to the POSIX emulation layer, and another one that targets the plain Win32 API (with a few convenience functions thrown in). Git for Windows' executables are built using the latter, and therefore they are really just Win32 programs. To discern executables requiring the POSIX emulation layer from the ones that do not, the latter are called MinGW (Minimal GNU for Windows) when the former are called MSys executables. This reliance on MSys incurred challenges, too, though: some of our changes to the MSys runtime -- necessary to support Git for Windows better -- were not accepted upstream, so we had to maintain our own fork. Also, the MSys runtime was not developed further to support e.g. UTF-8 or 64-bit, and apart from lacking a package management system until much later (when mingw-get was introduced), many packages provided by the MSys/MinGW project lag behind the respective source code versions, in particular Bash and OpenSSL. For a while, the Git for Windows project tried to remedy the situation by trying to build newer versions of those packages, but the situation quickly became untenable, especially with problems like the Heartbleed bug requiring swift action that has nothing to do with developing Git for Windows further. Happily, in the meantime the MSys2 project (https://msys2.github.io/) emerged, and was chosen to be the base of the Git for Windows 2.x. Just like MSys, MSys2 is a stripped down version of Cygwin, but it is actively kept up-to-date with Cygwin's source code. Thereby, it already supports Unicode internally, and it also offers the 64-bit support that we yearned for since the beginning of the Git for Windows project. MSys2 also ported the Pacman package management system from Arch Linux and uses it heavily. This brings the same convenience to which Linux users are used to from `yum` or `apt-get`, and to which MacOSX users are used to from Homebrew or MacPorts, or BSD users from the Ports system, to MSys2: a simple `pacman -Syu` will update all installed packages to the newest versions currently available. MSys2 is also *very* active, typically providing package updates multiple times per week. It still required a two-month effort to bring everything to a state where Git's test suite passes, many more months until the first official Git for Windows 2.x was released, and a couple of patches still await their submission to the respective upstream projects. Yet without MSys2, the modernization of Git for Windows would simply not have happened. This commit lays the ground work to supporting MSys2-based Git builds. Assisted-by: Waldek Maleska <weakcamel@users.github.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13 16:30:53 +03:00
INSTALL = /bin/install
INTERNAL_QSORT = YesPlease
HAVE_LIBCHARSET_H = YesPlease
mingw: let's use gettext with MSYS2 This solves two problems: - we now have proper localisation even on Windows - we sidestep the infamous "BUG: your vsnprintf is broken (returned -1)" message when running "git init" (which otherwise prevents the entire test suite from running) because libintl.h overrides vsnprintf() with libintl_vsnprintf() [*1*] The latter issue is rather crucial, as *no* test passes in Git for Windows without this fix. Footnote *1*: gettext_git=http://git.savannah.gnu.org/cgit/gettext.git $gettext_git/tree/gettext-runtime/intl/libgnuintl.in.h#n380 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-26 17:34:16 +03:00
NO_GETTEXT =
mingw: do not trust MSYS2's MinGW gettext.sh It does not quite work because it produces DOS line endings which the shell does not like at all. This lets t0200-gettext-basic.sh, t0204-gettext-reencode-sanity.sh, t3406-rebase-message.sh, t3903-stash.sh, t7400-submodule-basic.sh, t7401-submodule-summary.sh, t7406-submodule-update.sh and t7407-submodule-foreach.sh pass in Git for Windows' SDK. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-26 17:34:30 +03:00
USE_GETTEXT_SCHEME = fallthrough
config.mak.uname: PCRE1 cleanup Style issue: a space was missing. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-06-22 13:42:41 +03:00
USE_LIBPCRE = YesPlease
config.mak.uname: support MSys2 For a long time, Git for Windows lagged behind Git's 2.x releases because the Git for Windows developers wanted to let that big jump coincide with a well-needed jump away from MSys to MSys2. To understand why this is such a big issue, it needs to be noted that many parts of Git are not written in portable C, but instead Git relies on a POSIX shell and Perl to be available. To support the scripts, Git for Windows has to ship a minimal POSIX emulation layer with Bash and Perl thrown in, and when the Git for Windows effort started in August 2007, this developer settled on using MSys, a stripped down version of Cygwin. Consequently, the original name of the project was "msysGit" (which, sadly, caused a *lot* of confusion because few Windows users know about MSys, and even less care). To compile the C code of Git for Windows, MSys was used, too: it sports two versions of the GNU C Compiler: one that links implicitly to the POSIX emulation layer, and another one that targets the plain Win32 API (with a few convenience functions thrown in). Git for Windows' executables are built using the latter, and therefore they are really just Win32 programs. To discern executables requiring the POSIX emulation layer from the ones that do not, the latter are called MinGW (Minimal GNU for Windows) when the former are called MSys executables. This reliance on MSys incurred challenges, too, though: some of our changes to the MSys runtime -- necessary to support Git for Windows better -- were not accepted upstream, so we had to maintain our own fork. Also, the MSys runtime was not developed further to support e.g. UTF-8 or 64-bit, and apart from lacking a package management system until much later (when mingw-get was introduced), many packages provided by the MSys/MinGW project lag behind the respective source code versions, in particular Bash and OpenSSL. For a while, the Git for Windows project tried to remedy the situation by trying to build newer versions of those packages, but the situation quickly became untenable, especially with problems like the Heartbleed bug requiring swift action that has nothing to do with developing Git for Windows further. Happily, in the meantime the MSys2 project (https://msys2.github.io/) emerged, and was chosen to be the base of the Git for Windows 2.x. Just like MSys, MSys2 is a stripped down version of Cygwin, but it is actively kept up-to-date with Cygwin's source code. Thereby, it already supports Unicode internally, and it also offers the 64-bit support that we yearned for since the beginning of the Git for Windows project. MSys2 also ported the Pacman package management system from Arch Linux and uses it heavily. This brings the same convenience to which Linux users are used to from `yum` or `apt-get`, and to which MacOSX users are used to from Homebrew or MacPorts, or BSD users from the Ports system, to MSys2: a simple `pacman -Syu` will update all installed packages to the newest versions currently available. MSys2 is also *very* active, typically providing package updates multiple times per week. It still required a two-month effort to bring everything to a state where Git's test suite passes, many more months until the first official Git for Windows 2.x was released, and a couple of patches still await their submission to the respective upstream projects. Yet without MSys2, the modernization of Git for Windows would simply not have happened. This commit lays the ground work to supporting MSys2-based Git builds. Assisted-by: Waldek Maleska <weakcamel@users.github.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13 16:30:53 +03:00
NO_CURL =
USE_NED_ALLOCATOR = YesPlease
mingw: move Git for Windows' system config where users expect it Git for Windows' prefix is `/mingw64/` (or `/mingw32/` for 32-bit versions), therefore the system config is located at the clunky location `C:\Program Files\Git\mingw64\etc\gitconfig`. This moves the system config into a more logical location: the `mingw64` part of `C:\Program Files\Git\mingw64\etc\gitconfig` never made sense, as it is a mere implementation detail. Let's skip the `mingw64` part and move this to `C:\Program Files\Git\etc\gitconfig`. Side note: in the rare (and not recommended) case a user chooses to install 32-bit Git for Windows on a 64-bit system, the path will of course be `C:\Program Files (x86)\Git\etc\gitconfig`. Background: During the Git for Windows v1.x days, the system config was located at `C:\Program Files (x86)\Git\etc\gitconfig`. With Git for Windows v2.x, it moved to `C:\Program Files\Git\mingw64\gitconfig` (or `C:\Program Files (x86)\Git\mingw32\gitconfig`). Rather than fixing it back then, we tried to introduce a "Windows-wide" config, but that never caught on. Likewise, we move the system `gitattributes` into the same directory. Obviously, we are cautious to do this only for the known install locations `/mingw64` and `/mingw32`; If anybody wants to override that while building their version of Git (e.g. via `make prefix=$HOME`), we leave the default location of the system config and gitattributes alone. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-06-22 13:46:46 +03:00
ifeq (/mingw64,$(subst 32,64,$(prefix)))
# Move system config into top-level /etc/
ETC_GITCONFIG = ../etc/gitconfig
ETC_GITATTRIBUTES = ../etc/gitattributes
endif
config.mak.uname: support MSys2 For a long time, Git for Windows lagged behind Git's 2.x releases because the Git for Windows developers wanted to let that big jump coincide with a well-needed jump away from MSys to MSys2. To understand why this is such a big issue, it needs to be noted that many parts of Git are not written in portable C, but instead Git relies on a POSIX shell and Perl to be available. To support the scripts, Git for Windows has to ship a minimal POSIX emulation layer with Bash and Perl thrown in, and when the Git for Windows effort started in August 2007, this developer settled on using MSys, a stripped down version of Cygwin. Consequently, the original name of the project was "msysGit" (which, sadly, caused a *lot* of confusion because few Windows users know about MSys, and even less care). To compile the C code of Git for Windows, MSys was used, too: it sports two versions of the GNU C Compiler: one that links implicitly to the POSIX emulation layer, and another one that targets the plain Win32 API (with a few convenience functions thrown in). Git for Windows' executables are built using the latter, and therefore they are really just Win32 programs. To discern executables requiring the POSIX emulation layer from the ones that do not, the latter are called MinGW (Minimal GNU for Windows) when the former are called MSys executables. This reliance on MSys incurred challenges, too, though: some of our changes to the MSys runtime -- necessary to support Git for Windows better -- were not accepted upstream, so we had to maintain our own fork. Also, the MSys runtime was not developed further to support e.g. UTF-8 or 64-bit, and apart from lacking a package management system until much later (when mingw-get was introduced), many packages provided by the MSys/MinGW project lag behind the respective source code versions, in particular Bash and OpenSSL. For a while, the Git for Windows project tried to remedy the situation by trying to build newer versions of those packages, but the situation quickly became untenable, especially with problems like the Heartbleed bug requiring swift action that has nothing to do with developing Git for Windows further. Happily, in the meantime the MSys2 project (https://msys2.github.io/) emerged, and was chosen to be the base of the Git for Windows 2.x. Just like MSys, MSys2 is a stripped down version of Cygwin, but it is actively kept up-to-date with Cygwin's source code. Thereby, it already supports Unicode internally, and it also offers the 64-bit support that we yearned for since the beginning of the Git for Windows project. MSys2 also ported the Pacman package management system from Arch Linux and uses it heavily. This brings the same convenience to which Linux users are used to from `yum` or `apt-get`, and to which MacOSX users are used to from Homebrew or MacPorts, or BSD users from the Ports system, to MSys2: a simple `pacman -Syu` will update all installed packages to the newest versions currently available. MSys2 is also *very* active, typically providing package updates multiple times per week. It still required a two-month effort to bring everything to a state where Git's test suite passes, many more months until the first official Git for Windows 2.x was released, and a couple of patches still await their submission to the respective upstream projects. Yet without MSys2, the modernization of Git for Windows would simply not have happened. This commit lays the ground work to supporting MSys2-based Git builds. Assisted-by: Waldek Maleska <weakcamel@users.github.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13 16:30:53 +03:00
else
COMPAT_CFLAGS += -D__USE_MINGW_ANSI_STDIO
NO_CURL = YesPlease
endif
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
endif
endif
ifeq ($(uname_S),QNX)
COMPAT_CFLAGS += -DSA_RESTART=0
Allow building with xmlparse.h expat 1.1 and 1.2 provide xmlparse.h instead of expat.h. Include the former on systems that define the EXPAT_NEEDS_XMLPARSE_H variable and define that variable on QNX systems, which ship with expat 1.1. Signed-off-by: Matt Kraai <matt.kraai@amo.abbott.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-12 02:03:45 +04:00
EXPAT_NEEDS_XMLPARSE_H = YesPlease
Makefile: hoist uname autodetection to config.mak.uname Our Makefile first sets up some sane per-platform defaults by looking at "uname", then modifies that according to the results of autoconf (if any), then modifies that according to the user's wishes in config.mak. For sub-Makefiles like Documentation/Makefile, the latter two are available, but the uname defaults are available only to the main Makefile. This hasn't been a problem so far, because the sub-Makefiles do not rely on any of those automatic settings to do their work. This patch puts the uname magic into its own file so it can be reused in other Makefiles, opening up the possibility of new knobs. Note that we leave one reference to uname in the top-level Makefile: if we are on Darwin, we must check the NO_FINK and NO_DARWIN_PORTS settings. But because we are combining uname settings with user-options, we must do so after all of the config is loaded. This is acceptable, as the resulting conditionals are about setting variables specific to the top-level Makefile (and if that ever changes, we can hoist them into a separate post-config include, too). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
HAVE_STRINGS_H = YesPlease
NEEDS_SOCKET = YesPlease
NO_GETPAGESIZE = YesPlease
NO_ICONV = YesPlease
NO_MEMMEM = YesPlease
NO_MKDTEMP = YesPlease
NO_NSEC = YesPlease
NO_PTHREADS = YesPlease
NO_STRCASESTR = YesPlease
NO_STRLCPY = YesPlease
endif
msvc: add a Makefile target to pre-generate the Visual Studio solution The entire idea of generating the VS solution makes only sense if we generate it via Continuous Integration; otherwise potential users would still have to download the entire Git for Windows SDK. If we pre-generate the Visual Studio solution, Git can be built entirely within Visual Studio, and the test scripts can be run in a regular Git for Windows (e.g. the Portable Git flavor, which does not include a full GCC toolchain and therefore weighs only about a tenth of Git for Windows' SDK). So let's just add a target in the Makefile that can be used to generate said solution; The generated files will then be committed so that they can be pushed to a branch ready to check out by Visual Studio users. To make things even more useful, we also generate and commit other files that are required to run the test suite, such as templates and bin-wrappers: with this, developers can run the test suite in a regular Git Bash after building the solution in Visual Studio. Note: for this build target, we do not actually need to initialize the `vcpkg` system, so we don't. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29 23:08:12 +03:00
vcxproj:
# Require clean work tree
git update-index -q --refresh && \
git diff-files --quiet && \
git diff-index --cached --quiet HEAD --
# Make .vcxproj files and add them
perl contrib/buildsystems/generate -g Vcxproj
git add -f git.sln {*,*/lib,t/helper/*}/*.vcxproj
vcxproj: only copy `git-remote-http.exe` once it was built In b18ae14a8f6 (vcxproj: also link-or-copy builtins, 2019-07-29), we started to copy or hard-link the built-ins as a post-build step of the `git` project. At the same time, we tried to copy or hard-link `git-remote-http.exe`, but it is quite possible that it was not built at that time. Let's move that latter task into a post-install step of the `git-remote-http` project instead. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-04 18:09:31 +03:00
# Generate the LinkOrCopyBuiltins.targets and LinkOrCopyRemoteHttp.targets file
vcxproj: also link-or-copy builtins The default location for `.exe` files linked by Visual Studio depends on the mode (debug vs release) and the architecture. Meaning: after a full build, there is a `git.exe` in the top-level directory, but none of the built-ins are linked.. When running a test script in Git Bash, it therefore would pick up the wrong, say, `git-receive-pack.exe`: the one installed at the same time as the Git Bash. Absolutely not what we want. We want to have confidence that our test covers the MSVC-built Git executables, and not some random stuff. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29 23:08:13 +03:00
(echo '<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">' && \
echo ' <Target Name="CopyBuiltins_AfterBuild" AfterTargets="AfterBuild">' && \
for name in $(BUILT_INS);\
do \
echo ' <Copy SourceFiles="$$(OutDir)\git.exe" DestinationFiles="$$(OutDir)\'"$$name"'" SkipUnchangedFiles="true" UseHardlinksIfPossible="true" />'; \
done && \
vcxproj: only copy `git-remote-http.exe` once it was built In b18ae14a8f6 (vcxproj: also link-or-copy builtins, 2019-07-29), we started to copy or hard-link the built-ins as a post-build step of the `git` project. At the same time, we tried to copy or hard-link `git-remote-http.exe`, but it is quite possible that it was not built at that time. Let's move that latter task into a post-install step of the `git-remote-http` project instead. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-04 18:09:31 +03:00
echo ' </Target>' && \
echo '</Project>') >git/LinkOrCopyBuiltins.targets
(echo '<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">' && \
echo ' <Target Name="CopyBuiltins_AfterBuild" AfterTargets="AfterBuild">' && \
vcxproj: also link-or-copy builtins The default location for `.exe` files linked by Visual Studio depends on the mode (debug vs release) and the architecture. Meaning: after a full build, there is a `git.exe` in the top-level directory, but none of the built-ins are linked.. When running a test script in Git Bash, it therefore would pick up the wrong, say, `git-receive-pack.exe`: the one installed at the same time as the Git Bash. Absolutely not what we want. We want to have confidence that our test covers the MSVC-built Git executables, and not some random stuff. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29 23:08:13 +03:00
for name in $(REMOTE_CURL_ALIASES); \
do \
echo ' <Copy SourceFiles="$$(OutDir)\'"$(REMOTE_CURL_PRIMARY)"'" DestinationFiles="$$(OutDir)\'"$$name"'" SkipUnchangedFiles="true" UseHardlinksIfPossible="true" />'; \
done && \
echo ' </Target>' && \
vcxproj: only copy `git-remote-http.exe` once it was built In b18ae14a8f6 (vcxproj: also link-or-copy builtins, 2019-07-29), we started to copy or hard-link the built-ins as a post-build step of the `git` project. At the same time, we tried to copy or hard-link `git-remote-http.exe`, but it is quite possible that it was not built at that time. Let's move that latter task into a post-install step of the `git-remote-http` project instead. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-04 18:09:31 +03:00
echo '</Project>') >git-remote-http/LinkOrCopyRemoteHttp.targets
git add -f git/LinkOrCopyBuiltins.targets git-remote-http/LinkOrCopyRemoteHttp.targets
vcxproj: also link-or-copy builtins The default location for `.exe` files linked by Visual Studio depends on the mode (debug vs release) and the architecture. Meaning: after a full build, there is a `git.exe` in the top-level directory, but none of the built-ins are linked.. When running a test script in Git Bash, it therefore would pick up the wrong, say, `git-receive-pack.exe`: the one installed at the same time as the Git Bash. Absolutely not what we want. We want to have confidence that our test covers the MSVC-built Git executables, and not some random stuff. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29 23:08:13 +03:00
Makefile: stop hardcoding {command,config}-list.h Change various places that hardcode the names of these two files to refer to either $(GENERATED_H), or to a new generated-hdrs target. That target is consistent with the *-objs targets I recently added in 029bac01a8 (Makefile: add {program,xdiff,test,git,fuzz}-objs & objects targets, 2021-02-23). A subsequent commit will add a new generated hook-list.h. By doing this refactoring we'll only need to add the new file to the GENERATED_H variable, not EXCEPT_HDRS, the vcbuild/README etc. Hardcoding command-list.h there seems to have been a case of copy/paste programming in 976aaedca0 (msvc: add a Makefile target to pre-generate the Visual Studio solution, 2019-07-29). The config-list.h was added later in 709df95b78 (help: move list_config_help to builtin/help, 2020-04-16). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-23 13:29:57 +03:00
# Add generated headers
$(MAKE) MSVC=1 SKIP_VCPKG=1 prefix=/mingw64 $(GENERATED_H)
git add -f $(GENERATED_H)
msvc: add a Makefile target to pre-generate the Visual Studio solution The entire idea of generating the VS solution makes only sense if we generate it via Continuous Integration; otherwise potential users would still have to download the entire Git for Windows SDK. If we pre-generate the Visual Studio solution, Git can be built entirely within Visual Studio, and the test scripts can be run in a regular Git for Windows (e.g. the Portable Git flavor, which does not include a full GCC toolchain and therefore weighs only about a tenth of Git for Windows' SDK). So let's just add a target in the Makefile that can be used to generate said solution; The generated files will then be committed so that they can be pushed to a branch ready to check out by Visual Studio users. To make things even more useful, we also generate and commit other files that are required to run the test suite, such as templates and bin-wrappers: with this, developers can run the test suite in a regular Git Bash after building the solution in Visual Studio. Note: for this build target, we do not actually need to initialize the `vcpkg` system, so we don't. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29 23:08:12 +03:00
# Add scripts
rm -f perl/perl.mak
vcxproj: include more generated files In the CI builds, we bundle all generated files into a so-called artifacts `.tar` file, so that the test phase can fan out into multiple parallel builds. This patch makes sure that all files are included in the `vcxproj` target which are needed for that artifacts `.tar` file. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-04 18:09:32 +03:00
$(MAKE) MSVC=1 SKIP_VCPKG=1 prefix=/mingw64 $(SCRIPT_LIB) $(SCRIPTS)
msvc: add a Makefile target to pre-generate the Visual Studio solution The entire idea of generating the VS solution makes only sense if we generate it via Continuous Integration; otherwise potential users would still have to download the entire Git for Windows SDK. If we pre-generate the Visual Studio solution, Git can be built entirely within Visual Studio, and the test scripts can be run in a regular Git for Windows (e.g. the Portable Git flavor, which does not include a full GCC toolchain and therefore weighs only about a tenth of Git for Windows' SDK). So let's just add a target in the Makefile that can be used to generate said solution; The generated files will then be committed so that they can be pushed to a branch ready to check out by Visual Studio users. To make things even more useful, we also generate and commit other files that are required to run the test suite, such as templates and bin-wrappers: with this, developers can run the test suite in a regular Git Bash after building the solution in Visual Studio. Note: for this build target, we do not actually need to initialize the `vcpkg` system, so we don't. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29 23:08:12 +03:00
# Strip out the sane tool path, needed only for building
sed -i '/^git_broken_path_fix ".*/d' git-sh-setup
vcxproj: include more generated files In the CI builds, we bundle all generated files into a so-called artifacts `.tar` file, so that the test phase can fan out into multiple parallel builds. This patch makes sure that all files are included in the `vcxproj` target which are needed for that artifacts `.tar` file. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-04 18:09:32 +03:00
git add -f $(SCRIPT_LIB) $(SCRIPTS)
msvc: add a Makefile target to pre-generate the Visual Studio solution The entire idea of generating the VS solution makes only sense if we generate it via Continuous Integration; otherwise potential users would still have to download the entire Git for Windows SDK. If we pre-generate the Visual Studio solution, Git can be built entirely within Visual Studio, and the test scripts can be run in a regular Git for Windows (e.g. the Portable Git flavor, which does not include a full GCC toolchain and therefore weighs only about a tenth of Git for Windows' SDK). So let's just add a target in the Makefile that can be used to generate said solution; The generated files will then be committed so that they can be pushed to a branch ready to check out by Visual Studio users. To make things even more useful, we also generate and commit other files that are required to run the test suite, such as templates and bin-wrappers: with this, developers can run the test suite in a regular Git Bash after building the solution in Visual Studio. Note: for this build target, we do not actually need to initialize the `vcpkg` system, so we don't. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29 23:08:12 +03:00
# Add Perl module
$(MAKE) $(LIB_PERL_GEN)
git add -f perl/build
# Add bin-wrappers, for testing
rm -rf bin-wrappers/
$(MAKE) MSVC=1 SKIP_VCPKG=1 prefix=/mingw64 $(test_bindir_programs)
# Ensure that the GIT_EXEC_PATH is a Unix-y one, and that the absolute
# path of the repository is not hard-coded (GIT_EXEC_PATH will be set
# by test-lib.sh according to the current setup)
sed -i -e 's/^\(GIT_EXEC_PATH\)=.*/test -n "$${\1##*:*}" ||\
\1="$$(cygpath -u "$$\1")"/' \
-e "s|'$$(pwd)|\"\$$GIT_EXEC_PATH\"'|g" bin-wrappers/*
# Ensure that test-* helpers find the .dll files copied to top-level
sed -i 's|^PATH=.*|&:"$$GIT_EXEC_PATH"|' bin-wrappers/test-*
# We do not want to force hard-linking builtins
sed -i 's|\(git\)-\([-a-z]*\)\.exe"|\1.exe" \2|g' \
bin-wrappers/git-{receive-pack,upload-archive}
git add -f $(test_bindir_programs)
# remote-ext is a builtin, but invoked as if it were external
sed 's|receive-pack|remote-ext|g' \
<bin-wrappers/git-receive-pack >bin-wrappers/git-remote-ext
git add -f bin-wrappers/git-remote-ext
# Add templates
$(MAKE) -C templates
git add -f templates/boilerplates.made templates/blt/
vcxproj: include more generated files In the CI builds, we bundle all generated files into a so-called artifacts `.tar` file, so that the test phase can fan out into multiple parallel builds. This patch makes sure that all files are included in the `vcxproj` target which are needed for that artifacts `.tar` file. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-04 18:09:32 +03:00
# Add the translated messages
make MSVC=1 SKIP_VCPKG=1 prefix=/mingw64 $(MOFILES)
git add -f $(MOFILES)
msvc: add a Makefile target to pre-generate the Visual Studio solution The entire idea of generating the VS solution makes only sense if we generate it via Continuous Integration; otherwise potential users would still have to download the entire Git for Windows SDK. If we pre-generate the Visual Studio solution, Git can be built entirely within Visual Studio, and the test scripts can be run in a regular Git for Windows (e.g. the Portable Git flavor, which does not include a full GCC toolchain and therefore weighs only about a tenth of Git for Windows' SDK). So let's just add a target in the Makefile that can be used to generate said solution; The generated files will then be committed so that they can be pushed to a branch ready to check out by Visual Studio users. To make things even more useful, we also generate and commit other files that are required to run the test suite, such as templates and bin-wrappers: with this, developers can run the test suite in a regular Git Bash after building the solution in Visual Studio. Note: for this build target, we do not actually need to initialize the `vcpkg` system, so we don't. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29 23:08:12 +03:00
# Add build options
$(MAKE) MSVC=1 SKIP_VCPKG=1 prefix=/mingw64 GIT-BUILD-OPTIONS
git add -f GIT-BUILD-OPTIONS
# Commit the whole shebang
git commit -m "Generate Visual Studio solution" \
-m "Auto-generated by \`$(MAKE)$(MAKEFLAGS) $@\`"