mirrors/git - Incest Forge: Beyond sex. We incest.

mirrors/git

mirror of https://github.com/git/git.git synced 2024-10-30 22:07:53 +01:00

620 lines

18 KiB

Text

Raw Normal View History

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-03 22:05:41 +01:00			`# Platform specific Makefile tweaks based on uname detection`

			`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')`

			`ifdef MSVC`
			`# avoid the MingW and Cygwin configuration sections`
			`uname_S := Windows`
			`uname_O := Windows`
			`endif`

			`# 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 15:22:50 +01: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-03 22:05:41 +01: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 02:05:42 +02: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 21:00:56 +01: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 00:16:44 +02:00			`# -lrt is needed for clock_gettime on glibc <= 2.16`
			`NEEDS_LIBRT = 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 11:01:38 +02:00			`HAVE_GETDELIM = YesPlease`
sane_grep: pass "-a" if grep accepts it Newer versions of GNU grep is reported to be pickier when we feed a non-ASCII input and break some Porcelain scripts. As we know we do not feed random binary file to our own sane_grep wrapper, allow us to always pass "-a" by setting SANE_TEXT_GREP=-a Makefile variable to work it around. Signed-off-by: Junio C Hamano <gitster@pobox.com> 2016-03-09 00:47:57 +01:00			`SANE_TEXT_GREP=-a`
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 12:16:48 +02: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 17:36:17 +02: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 17:05:44 +02:00			`PROCFS_EXECUTABLE_PATH = /proc/self/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-03 22:05:41 +01: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 15:22:50 +01: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-03 22:05:41 +01: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 12:16:48 +02: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-03 22:05:41 +01: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 19:02:46 +02: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-03 22:05:41 +01: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 09:46:11 +02: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-03 22:05:41 +01: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-02 23:15:43 +02:00			ifeq ($(shell test "`expr "$(uname_R)" : '\([0-9][0-9]*\)\.'`" -ge 11 && echo 1),1)
			`HAVE_GETDELIM = 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-03 22:05:41 +01: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 00:15:20 +01: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 08:14:36 +01: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 06:44:33 +02: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 17:05:44 +02:00			`HAVE_NS_GET_EXECUTABLE_PATH = 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-03 22:05:41 +01: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 15:22:50 +01: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-03 22:05:41 +01: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 15:22:50 +01: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-03 22:05:41 +01: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 01:08:30 +02: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 01:08:28 +02: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-03 22:05:41 +01: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 15:22:50 +01: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-03 22:05:41 +01: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 22:30:28 +02: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 10:00:10 +02: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 05:33:30 +01: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 20:43:17 +02: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-03 22:05:41 +01: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 10:33:42 +02: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-03 22:05:41 +01: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 18:21:25 +02: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-03 22:05:41 +01:00			`HAVE_PATHS_H = YesPlease`
date: recognize bogus FreeBSD gmtime output Most gmtime implementations return a NULL value when they encounter an error (and this behavior is specified by ANSI C and POSIX). FreeBSD's implementation, however, will simply leave the "struct tm" untouched. Let's also recognize this and convert it to a NULL (with this patch, t4212 should pass on FreeBSD). Reported-by: René Scharfe <l.s.r@web.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-04-01 23:28:42 +02:00			`GMTIME_UNRELIABLE_ERRORS = UnfortunatelyYes`
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 08:14:36 +01: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 17:05:44 +02:00			`HAVE_BSD_KERN_PROC_SYSCTL = YesPlease`
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 13:40:25 +02: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 12:16:48 +02: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 15:14:41 +01: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-03 22:05:41 +01: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 08:14:36 +01: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 17:05:44 +02:00			`HAVE_BSD_KERN_PROC_SYSCTL = YesPlease`
			`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 03:43:20 +01: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 15:14:41 +01: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 15:36:45 +01: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 08:14:36 +01:00			`HAVE_BSD_SYSCTL = 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-03 22:05:41 +01: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 08:14:36 +01: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 17:05:44 +02:00			`HAVE_BSD_KERN_PROC_SYSCTL = YesPlease`
			`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-03 22:05:41 +01: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 15:54:30 +02: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-03 22:05:41 +01:00			`FREAD_READS_DIRECTORIES = UnfortunatelyYes`
			`INTERNAL_QSORT = UnfortunatelyYes`
			`NEEDS_LIBICONV = YesPlease`
			`BASIC_CFLAGS += -D_LARGE_FILES`
			`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 15:22:50 +01: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-03 22:05:41 +01:00			`NO_STRLCPY = YesPlease`
			`HAVE_PATHS_H = YesPlease`
			`LIBC_CONTAINS_LIBINTL = YesPlease`
			`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 = ;`
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 15:22:50 +01: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-03 22:05:41 +01: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`
			`# NEEDS_LIBICONV = YesPlease`
			`NO_ICONV = YesPlease`
			`NO_STRTOUMAX = YesPlease`
			`NO_MKDTEMP = YesPlease`
			`SNPRINTF_RETURNS_BOGUS = YesPlease`
			`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 17:05:46 +02: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-03 22:05:41 +01:00			`NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease`
			`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 10:00:10 +02: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-03 22:05:41 +01: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 01:21:53 +02: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-03 22:05:41 +01:00			`NO_PYTHON = YesPlease`
			`BLK_SHA1 = 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 19:33:57 +01: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-03 22:05:41 +01:00			`NO_POSIX_GOODIES = UnfortunatelyYes`
			`NATIVE_CRLF = YesPlease`
			`DEFAULT_HELP_FORMAT = html`

			`CC = compat/vcbuild/scripts/clink.pl`
			`AR = compat/vcbuild/scripts/lib.pl`
			`CFLAGS =`
			`BASIC_CFLAGS = -nologo -I. -I../zlib -Icompat/vcbuild -Icompat/vcbuild/include -DWIN32 -D_CONSOLE -DHAVE_STRING_H -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE`
			`COMPAT_OBJS = compat/msvc.o compat/winansi.o \`
			`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-22 23:25:02 +01: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-03 22:05:41 +01:00			`compat/win32/dirent.o`
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 15:22:50 +01:00			`COMPAT_CFLAGS = -D__USE_MINGW_ACCESS -DNOGDI -DHAVE_STRING_H -Icompat -Icompat/regex -Icompat/win32 -DSTRIP_EXTENSION=\".exe\"`
MSVC: link dynamically to the CRT Dynamic linking is generally preferred over static linking, and MSVCRT.dll has been integral part of Windows for a long time. This also fixes linker warnings for _malloc and _free in zlib.lib, which seems to be compiled for MSVCRT.dll already. The DLL version also exports some of the CRT initialization functions, which are hidden in the static libcmt.lib (e.g. __wgetmainargs, required by subsequent Unicode patches). Signed-off-by: Karsten Blees <blees@dcon.de> Signed-off-by: Stepan Kasal <kasal@ucw.cz> Acked-by: Sebastian Schuberth <sschuberth@gmail.com> Acked-by: Marat Radchenko <marat@slonopotamus.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2011-01-07 17:20:21 +01:00			`BASIC_LDFLAGS = -IGNORE:4217 -IGNORE:4049 -NOLOGO -SUBSYSTEM:CONSOLE`
MSVC: link in invalidcontinue.obj for better POSIX compatibility By default, Windows abort()'s instead of setting errno=EINVAL when invalid arguments are passed to standard functions. For example, when PAGER quits and git detects it with errno=EPIPE on write(), check_pipe() in write_or_die.c tries raise(SIGPIPE) but since there is no SIGPIPE on Windows, it is treated as invalid argument, causing abort() and crash report window. Linking in invalidcontinue.obj (provided along with MS compiler) allows raise(SIGPIPE) to return with errno=EINVAL. Signed-off-by: Marat Radchenko <marat@slonopotamus.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-03-28 21:08:02 +01:00			`EXTLIBS = user32.lib advapi32.lib shell32.lib wininet.lib ws2_32.lib invalidcontinue.obj`
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-03 22:05:41 +01:00			`PTHREAD_LIBS =`
			`lib =`
read-cache: optionally disallow NTFS .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 NTFS and FAT32; 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 NTFS nor FAT32. 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.protectNTFS config option. Though this is expected to be most useful on Windows, we allow it to be set everywhere, as NTFS may be mounted on other platforms. The variable does default to on for Windows, though. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2014-12-16 23:46:59 +01:00			`BASIC_CFLAGS += -DPROTECT_NTFS_DEFAULT=1`
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-03 22:05:41 +01:00			`ifndef DEBUG`
MSVC: link dynamically to the CRT Dynamic linking is generally preferred over static linking, and MSVCRT.dll has been integral part of Windows for a long time. This also fixes linker warnings for _malloc and _free in zlib.lib, which seems to be compiled for MSVCRT.dll already. The DLL version also exports some of the CRT initialization functions, which are hidden in the static libcmt.lib (e.g. __wgetmainargs, required by subsequent Unicode patches). Signed-off-by: Karsten Blees <blees@dcon.de> Signed-off-by: Stepan Kasal <kasal@ucw.cz> Acked-by: Sebastian Schuberth <sschuberth@gmail.com> Acked-by: Marat Radchenko <marat@slonopotamus.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2011-01-07 17:20:21 +01:00			`BASIC_CFLAGS += -GL -Os -MD`
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-03 22:05:41 +01:00			`BASIC_LDFLAGS += -LTCG`
			`AR += -LTCG`
			`else`
MSVC: link dynamically to the CRT Dynamic linking is generally preferred over static linking, and MSVCRT.dll has been integral part of Windows for a long time. This also fixes linker warnings for _malloc and _free in zlib.lib, which seems to be compiled for MSVCRT.dll already. The DLL version also exports some of the CRT initialization functions, which are hidden in the static libcmt.lib (e.g. __wgetmainargs, required by subsequent Unicode patches). Signed-off-by: Karsten Blees <blees@dcon.de> Signed-off-by: Stepan Kasal <kasal@ucw.cz> Acked-by: Sebastian Schuberth <sschuberth@gmail.com> Acked-by: Marat Radchenko <marat@slonopotamus.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2011-01-07 17:20:21 +01:00			`BASIC_CFLAGS += -Zi -MDd`
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-03 22:05:41 +01:00			`endif`
			`X = .exe`
			`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-03 22:03:49 +01: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-03 22:05:41 +01: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-03 22:03:49 +01: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-03 22:05:41 +01: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-03 22:03:49 +01: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`
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-03 22:05:41 +01:00			`# As detected by './configure'.`
			`# Missdetected, hence commented out, see below.`
			`#NO_CURL = YesPlease`
			`# Added manually, see above.`
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-03 22:03:49 +01:00			`NEEDS_SSL_WITH_CURL = YesPlease`
			`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-03 22:05:41 +01: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-03 22:03:49 +01: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-03 22:05:41 +01: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-03 22:03:49 +01: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-03 22:05:41 +01: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 01:20:16 +01: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-03 22:05:41 +01: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`
			`# Bug report 10-120822-4477 submitted to HP NonStop development.`
			`MKDIR_WO_TRAILING_SLASH = YesPlease`
			`# RFE 10-120912-4693 submitted to HP NonStop development.`
			`NO_SETITIMER = UnfortunatelyYes`
			`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 18:26:11 +01: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-03 22:05:41 +01:00			`endif`
			`ifneq (,$(findstring MINGW,$(uname_S)))`
			`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 14:48:27 +02: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-03 22:05:41 +01: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`
			`NO_PERL_MAKEMAKER = 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 17:05:46 +02: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-03 22:05:41 +01:00			`NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease`
			`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 10:00:10 +02: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-03 22:05:41 +01: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 13:24:14 +02:00			`DEFAULT_HELP_FORMAT = html`
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 14:31:01 +01: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-03 22:05:41 +01: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-22 23:25:02 +01:00			`compat/win32/trace2_win32_process_info.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 05:33:30 +01: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-03 22:05:41 +01:00			`compat/win32/pthread.o compat/win32/syslog.o \`
			`compat/win32/dirent.o`
mingw: define WIN32 explicitly This helps VS Code's intellisense to figure out that we want to include windows.h, and that we want to define the minimum target Windows version as Windows Vista/2008R2. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-07-30 17:42:51 +02:00			`BASIC_CFLAGS += -DWIN32 -DPROTECT_NTFS_DEFAULT=1`
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-03 22:05:41 +01: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 01:56:24 +02: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-03 22:05:41 +01: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 01:56:24 +02: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 10:25:09 +02: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-03 22:05:41 +01:00			`X = .exe`
			`ifneq (,$(wildcard ../THIS_IS_MSYSGIT))`
			`htmldir = doc/git/html/`
			`prefix =`
			`INSTALL = /bin/install`
			`EXTLIBS += /mingw/lib/libz.a`
			`NO_R_TO_GCC_LINKER = YesPlease`
			`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-05 23:41:41 +01:00			`NO_GETTEXT = 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 14:30:53 +01:00			`COMPAT_CLFAGS += -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-03 22:05:41 +01:00			`else`
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 14:30:53 +01:00			`ifeq ($(shell expr "$(uname_R)" : '2\.'),2)`
			`# 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 14:31:01 +01:00			`prefix = /usr/`
			`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 11:19:49 +01:00			`HOST_CPU = i686`
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 14:31:01 +01: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 11:19:49 +01:00			`HOST_CPU = x86_64`
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 14:31:01 +01: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 14:30:53 +01:00			`CC = gcc`
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 17:16:37 +02:00			`COMPAT_CFLAGS += -D__USE_MINGW_ANSI_STDIO=0 -DDETECT_MSYS_TTY`
			`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 14:30:53 +01:00			`INSTALL = /bin/install`
			`NO_R_TO_GCC_LINKER = YesPlease`
			`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 15:34:16 +01: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 15:34:30 +01:00			`USE_GETTEXT_SCHEME = fallthrough`
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 14:30:53 +01:00			`USE_LIBPCRE= YesPlease`
grep: un-break building with PCRE >= 8.32 without --enable-jit Amend my change earlier in this series ("grep: add support for the PCRE v1 JIT API", 2017-04-11) to un-break the build on PCRE v1 versions later than 8.31 compiled without --enable-jit. As explained in that change and a later compatibility change in this series ("grep: un-break building with PCRE < 8.32", 2017-05-10) the pcre_jit_exec() function is a faster path to execute the JIT. Unfortunately there's no compatibility stub for that function compiled into the library if pcre_config(PCRE_CONFIG_JIT, &ret) would return 0, and no macro that can be used to check for it, so the only portable option to support builds without --enable-jit is via a new NO_LIBPCRE1_JIT=UnfortunatelyYes Makefile option[1]. Another option would be to make the JIT opt-in via USE_LIBPCRE1_JIT=YesPlease, after all it's not a default option of PCRE v1. I think it makes more sense to make it opt-out since even though it's not a default option, most packagers of PCRE seem to turn it on by default, with the notable exception of the MinGW package. Make the MinGW platform work by default by changing the build defaults to turn on NO_LIBPCRE1_JIT=UnfortunatelyYes. It is the only platform that turns on USE_LIBPCRE=YesPlease by default, see commit df5218b4c3 ("config.mak.uname: support MSys2", 2016-01-13) for that change. 1. "How do I support pcre1 JIT on all versions?" (https://lists.exim.org/lurker/thread/20170601.103148.10253788.en.html) 2. https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-pcre/PKGBUILD (referenced from "Re: PCRE v2 compile error, was Re: What's cooking in git.git (May 2017, #01; Mon, 1)"; <alpine.DEB.2.20.1705021756530.3480@virtualbox>) Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-06-01 20:20:55 +02:00			`NO_LIBPCRE1_JIT = UnfortunatelyYes`
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 14:30:53 +01:00			`NO_CURL =`
			`USE_NED_ALLOCATOR = YesPlease`
			`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-03 22:05:41 +01: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-11 23:03:45 +01: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-03 22:05:41 +01: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_R_TO_GCC_LINKER = YesPlease`
			`NO_STRCASESTR = YesPlease`
			`NO_STRLCPY = YesPlease`
			`endif`