Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
# Platform specific Makefile tweaks based on uname detection
|
|
|
|
|
|
2019-06-25 17:49:39 +03:00
|
|
|
# Define NO_SAFESEH if you need MSVC/Visual Studio to ignore the lack of
|
|
|
|
|
# Microsoft's Safe Exception Handling in libraries (such as zlib).
|
|
|
|
|
# Typically required for VS2013+/32-bit compilation on Vista+ versions.
|
|
|
|
|
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
uname_S := $(shell sh -c 'uname -s 2>/dev/null || echo not')
|
|
|
|
|
uname_M := $(shell sh -c 'uname -m 2>/dev/null || echo not')
|
|
|
|
|
uname_O := $(shell sh -c 'uname -o 2>/dev/null || echo not')
|
|
|
|
|
uname_R := $(shell sh -c 'uname -r 2>/dev/null || echo not')
|
|
|
|
|
uname_P := $(shell sh -c 'uname -p 2>/dev/null || echo not')
|
|
|
|
|
uname_V := $(shell sh -c 'uname -v 2>/dev/null || echo not')
|
|
|
|
|
|
2021-09-29 06:19:40 +03:00
|
|
|
ifneq ($(findstring MINGW,$(uname_S)),)
|
|
|
|
|
uname_S := MINGW
|
|
|
|
|
endif
|
|
|
|
|
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
ifdef MSVC
|
|
|
|
|
# avoid the MingW and Cygwin configuration sections
|
|
|
|
|
uname_S := Windows
|
|
|
|
|
uname_O := Windows
|
2019-06-25 17:49:39 +03:00
|
|
|
|
|
|
|
|
# Generate and include makefile variables that point to the
|
|
|
|
|
# currently installed set of MSVC command line tools.
|
|
|
|
|
compat/vcbuild/MSVC-DEFS-GEN: compat/vcbuild/find_vs_env.bat
|
|
|
|
|
@"$<" | tr '\\' / >"$@"
|
|
|
|
|
include compat/vcbuild/MSVC-DEFS-GEN
|
|
|
|
|
|
|
|
|
|
# See if vcpkg and the vcpkg-build versions of the third-party
|
|
|
|
|
# libraries that we use are installed. We include the result
|
|
|
|
|
# to get $(vcpkg_*) variables defined for the Makefile.
|
2019-07-29 23:08:12 +03:00
|
|
|
ifeq (,$(SKIP_VCPKG))
|
2019-06-25 17:49:39 +03:00
|
|
|
compat/vcbuild/VCPKG-DEFS: compat/vcbuild/vcpkg_install.bat
|
|
|
|
|
@"$<"
|
|
|
|
|
include compat/vcbuild/VCPKG-DEFS
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
endif
|
2019-07-29 23:08:12 +03:00
|
|
|
endif
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
|
|
|
|
|
# We choose to avoid "if .. else if .. else .. endif endif"
|
|
|
|
|
# because maintaining the nesting to match is a pain. If
|
|
|
|
|
# we had "elif" things would have been much nicer...
|
|
|
|
|
|
|
|
|
|
ifeq ($(uname_S),OSF1)
|
|
|
|
|
# Need this for u_short definitions et al
|
|
|
|
|
BASIC_CFLAGS += -D_OSF_SOURCE
|
|
|
|
|
SOCKLEN_T = int
|
|
|
|
|
NO_STRTOULL = YesPlease
|
|
|
|
|
NO_NSEC = YesPlease
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_S),Linux)
|
Portable alloca for Git
In the next patch we'll have to use alloca() for performance reasons,
but since alloca is non-standardized and is not portable, let's have a
trick with compatibility wrappers:
1. at configure time, determine, do we have working alloca() through
alloca.h, and define
#define HAVE_ALLOCA_H
if yes.
2. in code
#ifdef HAVE_ALLOCA_H
# include <alloca.h>
# define xalloca(size) (alloca(size))
# define xalloca_free(p) do {} while(0)
#else
# define xalloca(size) (xmalloc(size))
# define xalloca_free(p) (free(p))
#endif
and use it like
func() {
p = xalloca(size);
...
xalloca_free(p);
}
This way, for systems, where alloca is available, we'll have optimal
on-stack allocations with fast executions. On the other hand, on
systems, where alloca is not available, this gracefully fallbacks to
xmalloc/free.
Both autoconf and config.mak.uname configurations were updated. For
autoconf, we are not bothering considering cases, when no alloca.h is
available, but alloca() works some other way - its simply alloca.h is
available and works or not, everything else is deep legacy.
For config.mak.uname, I've tried to make my almost-sure guess for where
alloca() is available, but since I only have access to Linux it is the
only change I can be sure about myself, with relevant to other changed
systems people Cc'ed.
NOTE
SunOS and Windows had explicit -DHAVE_ALLOCA_H in their configurations.
I've changed that to now-common HAVE_ALLOCA_H=YesPlease which should be
correct.
Cc: Brandon Casey <drafnel@gmail.com>
Cc: Marius Storm-Olsen <mstormo@gmail.com>
Cc: Johannes Sixt <j6t@kdbg.org>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Cc: Gerrit Pape <pape@smarden.org>
Cc: Petr Salinger <Petr.Salinger@seznam.cz>
Cc: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Thomas Schwinge <thomas@codesourcery.com> (GNU Hurd changes)
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-27 18:22:50 +04:00
|
|
|
HAVE_ALLOCA_H = YesPlease
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
NO_STRLCPY = YesPlease
|
|
|
|
|
HAVE_PATHS_H = YesPlease
|
|
|
|
|
LIBC_CONTAINS_LIBINTL = YesPlease
|
|
|
|
|
HAVE_DEV_TTY = YesPlease
|
2014-07-12 04:05:42 +04:00
|
|
|
HAVE_CLOCK_GETTIME = YesPlease
|
2015-01-08 23:00:56 +03:00
|
|
|
HAVE_CLOCK_MONOTONIC = YesPlease
|
2016-07-11 01:16:44 +03:00
|
|
|
# -lrt is needed for clock_gettime on glibc <= 2.16
|
|
|
|
|
NEEDS_LIBRT = YesPlease
|
2022-03-11 01:43:20 +03:00
|
|
|
HAVE_SYNC_FILE_RANGE = YesPlease
|
2015-04-16 12:01:38 +03:00
|
|
|
HAVE_GETDELIM = YesPlease
|
2017-05-03 13:16:48 +03:00
|
|
|
FREAD_READS_DIRECTORIES = UnfortunatelyYes
|
2018-04-15 18:36:17 +03:00
|
|
|
BASIC_CFLAGS += -DHAVE_SYSINFO
|
2018-04-10 18:05:44 +03:00
|
|
|
PROCFS_EXECUTABLE_PATH = /proc/self/exe
|
tr2: log parent process name
It can be useful to tell who invoked Git - was it invoked manually by a
user via CLI or script? By an IDE? In some cases - like 'repo' tool -
we can influence the source code and set the GIT_TRACE2_PARENT_SID
environment variable from the caller process. In 'repo''s case, that
parent SID is manipulated to include the string "repo", which means we
can positively identify when Git was invoked by 'repo' tool. However,
identifying parents that way requires both that we know which tools
invoke Git and that we have the ability to modify the source code of
those tools. It cannot scale to keep up with the various IDEs and
wrappers which use Git, most of which we don't know about. Learning
which tools and wrappers invoke Git, and how, would give us insight to
decide where to improve Git's usability and performance.
Unfortunately, there's no cross-platform reliable way to gather the name
of the parent process. If procfs is present, we can use that; otherwise
we will need to discover the name another way. However, the process ID
should be sufficient to look up the process name on most platforms, so
that code may be shareable.
Git for Windows gathers similar information and logs it as a "data_json"
event. However, since "data_json" has a variable format, it is difficult
to parse effectively in some languages; instead, let's pursue a
dedicated "cmd_ancestry" event to record information about the ancestry
of the current process and a consistent, parseable way.
Git for Windows also gathers information about more than one generation
of parent. In Linux further ancestry info can be gathered with procfs,
but it's unwieldy to do so. In the interest of later moving Git for
Windows ancestry logging to the 'cmd_ancestry' event, and in the
interest of later adding more ancestry to the Linux implementation - or
of adding this functionality to other platforms which have an easier
time walking the process tree - let's make 'cmd_ancestry' accept an
array of parentage.
Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-22 04:27:07 +03:00
|
|
|
HAVE_PLATFORM_PROCINFO = YesPlease
|
|
|
|
|
COMPAT_OBJS += compat/linux/procinfo.o
|
2022-01-16 05:05:20 +03:00
|
|
|
# centos7/rhel7 provides gcc 4.8.5 and zlib 1.2.7.
|
|
|
|
|
ifneq ($(findstring .el7.,$(uname_R)),)
|
|
|
|
|
BASIC_CFLAGS += -std=c99
|
|
|
|
|
endif
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_S),GNU/kFreeBSD)
|
Portable alloca for Git
In the next patch we'll have to use alloca() for performance reasons,
but since alloca is non-standardized and is not portable, let's have a
trick with compatibility wrappers:
1. at configure time, determine, do we have working alloca() through
alloca.h, and define
#define HAVE_ALLOCA_H
if yes.
2. in code
#ifdef HAVE_ALLOCA_H
# include <alloca.h>
# define xalloca(size) (alloca(size))
# define xalloca_free(p) do {} while(0)
#else
# define xalloca(size) (xmalloc(size))
# define xalloca_free(p) (free(p))
#endif
and use it like
func() {
p = xalloca(size);
...
xalloca_free(p);
}
This way, for systems, where alloca is available, we'll have optimal
on-stack allocations with fast executions. On the other hand, on
systems, where alloca is not available, this gracefully fallbacks to
xmalloc/free.
Both autoconf and config.mak.uname configurations were updated. For
autoconf, we are not bothering considering cases, when no alloca.h is
available, but alloca() works some other way - its simply alloca.h is
available and works or not, everything else is deep legacy.
For config.mak.uname, I've tried to make my almost-sure guess for where
alloca() is available, but since I only have access to Linux it is the
only change I can be sure about myself, with relevant to other changed
systems people Cc'ed.
NOTE
SunOS and Windows had explicit -DHAVE_ALLOCA_H in their configurations.
I've changed that to now-common HAVE_ALLOCA_H=YesPlease which should be
correct.
Cc: Brandon Casey <drafnel@gmail.com>
Cc: Marius Storm-Olsen <mstormo@gmail.com>
Cc: Johannes Sixt <j6t@kdbg.org>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Cc: Gerrit Pape <pape@smarden.org>
Cc: Petr Salinger <Petr.Salinger@seznam.cz>
Cc: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Thomas Schwinge <thomas@codesourcery.com> (GNU Hurd changes)
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-27 18:22:50 +04:00
|
|
|
HAVE_ALLOCA_H = YesPlease
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
NO_STRLCPY = YesPlease
|
|
|
|
|
HAVE_PATHS_H = YesPlease
|
|
|
|
|
DIR_HAS_BSD_GROUP_SEMANTICS = YesPlease
|
|
|
|
|
LIBC_CONTAINS_LIBINTL = YesPlease
|
2017-05-03 13:16:48 +03:00
|
|
|
FREAD_READS_DIRECTORIES = UnfortunatelyYes
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_S),UnixWare)
|
|
|
|
|
CC = cc
|
|
|
|
|
NEEDS_SOCKET = YesPlease
|
|
|
|
|
NEEDS_NSL = YesPlease
|
|
|
|
|
NEEDS_SSL_WITH_CRYPTO = YesPlease
|
|
|
|
|
NEEDS_LIBICONV = YesPlease
|
|
|
|
|
SHELL_PATH = /usr/local/bin/bash
|
|
|
|
|
NO_IPV6 = YesPlease
|
|
|
|
|
NO_HSTRERROR = YesPlease
|
|
|
|
|
BASIC_CFLAGS += -Kthread
|
|
|
|
|
BASIC_CFLAGS += -I/usr/local/include
|
|
|
|
|
BASIC_LDFLAGS += -L/usr/local/lib
|
|
|
|
|
INSTALL = ginstall
|
|
|
|
|
TAR = gtar
|
|
|
|
|
NO_STRCASESTR = YesPlease
|
|
|
|
|
NO_MEMMEM = YesPlease
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_S),SCO_SV)
|
|
|
|
|
ifeq ($(uname_R),3.2)
|
|
|
|
|
CFLAGS = -O2
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_R),5)
|
|
|
|
|
CC = cc
|
|
|
|
|
BASIC_CFLAGS += -Kthread
|
|
|
|
|
endif
|
|
|
|
|
NEEDS_SOCKET = YesPlease
|
|
|
|
|
NEEDS_NSL = YesPlease
|
|
|
|
|
NEEDS_SSL_WITH_CRYPTO = YesPlease
|
|
|
|
|
NEEDS_LIBICONV = YesPlease
|
|
|
|
|
SHELL_PATH = /usr/bin/bash
|
|
|
|
|
NO_IPV6 = YesPlease
|
|
|
|
|
NO_HSTRERROR = YesPlease
|
|
|
|
|
BASIC_CFLAGS += -I/usr/local/include
|
|
|
|
|
BASIC_LDFLAGS += -L/usr/local/lib
|
|
|
|
|
NO_STRCASESTR = YesPlease
|
|
|
|
|
NO_MEMMEM = YesPlease
|
|
|
|
|
INSTALL = ginstall
|
|
|
|
|
TAR = gtar
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_S),Darwin)
|
|
|
|
|
NEEDS_CRYPTO_WITH_SSL = YesPlease
|
|
|
|
|
NEEDS_SSL_WITH_CRYPTO = YesPlease
|
|
|
|
|
NEEDS_LIBICONV = YesPlease
|
2014-08-15 21:02:46 +04:00
|
|
|
# Note: $(uname_R) gives us the underlying Darwin version.
|
|
|
|
|
# - MacOS 10.0.* and MacOS 10.1.0 = Darwin 1.*
|
|
|
|
|
# - MacOS 10.x.* = Darwin (x+4).* for (1 <= x)
|
|
|
|
|
# i.e. "begins with [15678] and a dot" means "10.4.* or older".
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
ifeq ($(shell expr "$(uname_R)" : '[15678]\.'),2)
|
|
|
|
|
OLD_ICONV = UnfortunatelyYes
|
2014-08-15 11:46:11 +04:00
|
|
|
NO_APPLE_COMMON_CRYPTO = YesPlease
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
endif
|
|
|
|
|
ifeq ($(shell expr "$(uname_R)" : '[15]\.'),2)
|
|
|
|
|
NO_STRLCPY = YesPlease
|
|
|
|
|
endif
|
config.mak.uname: Darwin: define HAVE_GETDELIM for modern OS X releases
On Mac OS X, getdelim() first became available with Xcode 4.1[1], which
was released the same day as OS X 10.7 "Lion", so assume getdelim()
availability from 10.7 onward. (As of this writing, OS X is at 10.10
"Yosemite".)
According to Wikipedia[2], 4.1 was also available for download by paying
developers on OS X 10.6 "Snow Leopard", so it's possible that some 10.6
machines may have getdelim(). However, as strbuf's use of getdelim() is
purely an optimization, let's be conservative and assume 10.6 and
earlier lack getdelim().
[1]: Or, possibly with Xcode 4.0, but that version is no longer
available for download, or not available to non-paying developers,
so testing is not possible.
[2]: http://en.wikipedia.org/wiki/Xcode
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-03 00:15:43 +03:00
|
|
|
ifeq ($(shell test "`expr "$(uname_R)" : '\([0-9][0-9]*\)\.'`" -ge 11 && echo 1),1)
|
|
|
|
|
HAVE_GETDELIM = YesPlease
|
|
|
|
|
endif
|
2021-03-01 12:29:47 +03:00
|
|
|
ifeq ($(shell test "`expr "$(uname_R)" : '\([0-9][0-9]*\)\.'`" -ge 20 && echo 1),1)
|
|
|
|
|
OPEN_RETURNS_EINTR = UnfortunatelyYes
|
|
|
|
|
endif
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
NO_MEMMEM = YesPlease
|
|
|
|
|
USE_ST_TIMESPEC = YesPlease
|
|
|
|
|
HAVE_DEV_TTY = YesPlease
|
|
|
|
|
COMPAT_OBJS += compat/precompose_utf8.o
|
|
|
|
|
BASIC_CFLAGS += -DPRECOMPOSE_UNICODE
|
2014-12-16 02:15:20 +03:00
|
|
|
BASIC_CFLAGS += -DPROTECT_HFS_DEFAULT=1
|
2015-03-08 10:14:36 +03:00
|
|
|
HAVE_BSD_SYSCTL = YesPlease
|
2017-05-10 07:44:33 +03:00
|
|
|
FREAD_READS_DIRECTORIES = UnfortunatelyYes
|
2018-04-10 18:05:44 +03:00
|
|
|
HAVE_NS_GET_EXECUTABLE_PATH = YesPlease
|
wrapper: add a helper to generate numbers from a CSPRNG
There are many situations in which having access to a cryptographically
secure pseudorandom number generator (CSPRNG) is helpful. In the
future, we'll encounter one of these when dealing with temporary files.
To make this possible, let's add a function which reads from a system
CSPRNG and returns some bytes.
We know that all systems will have such an interface. A CSPRNG is
required for a secure TLS or SSH implementation and a Git implementation
which provided neither would be of little practical use. In addition,
POSIX is set to standardize getentropy(2) in the next version, so in the
(potentially distant) future we can rely on that.
For systems which lack one of the other interfaces, we provide the
ability to use OpenSSL's CSPRNG. OpenSSL is highly portable and
functions on practically every known OS, and we know it will have access
to some source of cryptographically secure randomness. We also provide
support for the arc4random in libbsd for folks who would prefer to use
that.
Because this is a security sensitive interface, we take some
precautions. We either succeed by filling the buffer completely as we
requested, or we fail. We don't return partial data because the caller
will almost never find that to be a useful behavior.
Specify a makefile knob which users can use to specify one or more
suitable CSPRNGs, and turn the multiple string options into a set of
defines, since we cannot match on strings in the preprocessor. We allow
multiple options to make the job of handling this in autoconf easier.
The order of options is important here. On systems with arc4random,
which is most of the BSDs, we use that, since, except on MirBSD and
macOS, it uses ChaCha20, which is extremely fast, and sits entirely in
userspace, avoiding a system call. We then prefer getrandom over
getentropy, because the former has been available longer on Linux, and
then OpenSSL. Finally, if none of those are available, we use
/dev/urandom, because most Unix-like operating systems provide that API.
We prefer options that don't involve device files when possible because
those work in some restricted environments where device files may not be
available.
Set the configuration variables appropriately for Linux and the BSDs,
including macOS, as well as Windows and NonStop. We specifically only
consider versions which receive publicly available security support
here. For the same reason, we don't specify getrandom(2) on Linux,
because CentOS 7 doesn't support it in glibc (although its kernel does)
and we don't want to resort to making syscalls.
Finally, add a test helper to allow this to be tested by hand and in
tests. We don't add any tests, since invoking the CSPRNG is not likely
to produce interesting, reproducible results.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-18 00:56:16 +03:00
|
|
|
CSPRNG_METHOD = arc4random
|
2020-04-26 23:09:32 +03:00
|
|
|
|
|
|
|
|
# Workaround for `gettext` being keg-only and not even being linked via
|
|
|
|
|
# `brew link --force gettext`, should be obsolete as of
|
|
|
|
|
# https://github.com/Homebrew/homebrew-core/pull/53489
|
|
|
|
|
ifeq ($(shell test -d /usr/local/opt/gettext/ && echo y),y)
|
|
|
|
|
BASIC_CFLAGS += -I/usr/local/include -I/usr/local/opt/gettext/include
|
|
|
|
|
BASIC_LDFLAGS += -L/usr/local/lib -L/usr/local/opt/gettext/lib
|
|
|
|
|
ifeq ($(shell test -x /usr/local/opt/gettext/bin/msgfmt && echo y),y)
|
|
|
|
|
MSGFMT = /usr/local/opt/gettext/bin/msgfmt
|
|
|
|
|
endif
|
|
|
|
|
endif
|
2022-03-25 21:02:52 +03:00
|
|
|
|
|
|
|
|
# The builtin FSMonitor on MacOS builds upon Simple-IPC. Both require
|
|
|
|
|
# Unix domain sockets and PThreads.
|
|
|
|
|
ifndef NO_PTHREADS
|
|
|
|
|
ifndef NO_UNIX_SOCKETS
|
|
|
|
|
FSMONITOR_DAEMON_BACKEND = darwin
|
2022-05-27 00:47:01 +03:00
|
|
|
FSMONITOR_OS_SETTINGS = darwin
|
2022-03-25 21:02:52 +03:00
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
BASIC_LDFLAGS += -framework CoreServices
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_S),SunOS)
|
|
|
|
|
NEEDS_SOCKET = YesPlease
|
|
|
|
|
NEEDS_NSL = YesPlease
|
|
|
|
|
SHELL_PATH = /bin/bash
|
|
|
|
|
SANE_TOOL_PATH = /usr/xpg6/bin:/usr/xpg4/bin
|
Portable alloca for Git
In the next patch we'll have to use alloca() for performance reasons,
but since alloca is non-standardized and is not portable, let's have a
trick with compatibility wrappers:
1. at configure time, determine, do we have working alloca() through
alloca.h, and define
#define HAVE_ALLOCA_H
if yes.
2. in code
#ifdef HAVE_ALLOCA_H
# include <alloca.h>
# define xalloca(size) (alloca(size))
# define xalloca_free(p) do {} while(0)
#else
# define xalloca(size) (xmalloc(size))
# define xalloca_free(p) (free(p))
#endif
and use it like
func() {
p = xalloca(size);
...
xalloca_free(p);
}
This way, for systems, where alloca is available, we'll have optimal
on-stack allocations with fast executions. On the other hand, on
systems, where alloca is not available, this gracefully fallbacks to
xmalloc/free.
Both autoconf and config.mak.uname configurations were updated. For
autoconf, we are not bothering considering cases, when no alloca.h is
available, but alloca() works some other way - its simply alloca.h is
available and works or not, everything else is deep legacy.
For config.mak.uname, I've tried to make my almost-sure guess for where
alloca() is available, but since I only have access to Linux it is the
only change I can be sure about myself, with relevant to other changed
systems people Cc'ed.
NOTE
SunOS and Windows had explicit -DHAVE_ALLOCA_H in their configurations.
I've changed that to now-common HAVE_ALLOCA_H=YesPlease which should be
correct.
Cc: Brandon Casey <drafnel@gmail.com>
Cc: Marius Storm-Olsen <mstormo@gmail.com>
Cc: Johannes Sixt <j6t@kdbg.org>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Cc: Gerrit Pape <pape@smarden.org>
Cc: Petr Salinger <Petr.Salinger@seznam.cz>
Cc: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Thomas Schwinge <thomas@codesourcery.com> (GNU Hurd changes)
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-27 18:22:50 +04:00
|
|
|
HAVE_ALLOCA_H = YesPlease
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
NO_STRCASESTR = YesPlease
|
|
|
|
|
NO_MEMMEM = YesPlease
|
|
|
|
|
NO_MKDTEMP = YesPlease
|
|
|
|
|
NO_REGEX = YesPlease
|
|
|
|
|
NO_MSGFMT_EXTENDED_OPTIONS = YesPlease
|
|
|
|
|
HAVE_DEV_TTY = YesPlease
|
|
|
|
|
ifeq ($(uname_R),5.6)
|
|
|
|
|
SOCKLEN_T = int
|
|
|
|
|
NO_HSTRERROR = YesPlease
|
|
|
|
|
NO_IPV6 = YesPlease
|
|
|
|
|
NO_SOCKADDR_STORAGE = YesPlease
|
|
|
|
|
NO_UNSETENV = YesPlease
|
|
|
|
|
NO_SETENV = YesPlease
|
|
|
|
|
NO_STRLCPY = YesPlease
|
|
|
|
|
NO_STRTOUMAX = YesPlease
|
|
|
|
|
GIT_TEST_CMP = cmp
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_R),5.7)
|
|
|
|
|
NEEDS_RESOLV = YesPlease
|
|
|
|
|
NO_IPV6 = YesPlease
|
|
|
|
|
NO_SOCKADDR_STORAGE = YesPlease
|
|
|
|
|
NO_UNSETENV = YesPlease
|
|
|
|
|
NO_SETENV = YesPlease
|
|
|
|
|
NO_STRLCPY = YesPlease
|
|
|
|
|
NO_STRTOUMAX = YesPlease
|
|
|
|
|
GIT_TEST_CMP = cmp
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_R),5.8)
|
|
|
|
|
NO_UNSETENV = YesPlease
|
|
|
|
|
NO_SETENV = YesPlease
|
|
|
|
|
NO_STRTOUMAX = YesPlease
|
|
|
|
|
GIT_TEST_CMP = cmp
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_R),5.9)
|
|
|
|
|
NO_UNSETENV = YesPlease
|
|
|
|
|
NO_SETENV = YesPlease
|
|
|
|
|
NO_STRTOUMAX = YesPlease
|
|
|
|
|
GIT_TEST_CMP = cmp
|
|
|
|
|
endif
|
|
|
|
|
INSTALL = /usr/ucb/install
|
|
|
|
|
TAR = gtar
|
Portable alloca for Git
In the next patch we'll have to use alloca() for performance reasons,
but since alloca is non-standardized and is not portable, let's have a
trick with compatibility wrappers:
1. at configure time, determine, do we have working alloca() through
alloca.h, and define
#define HAVE_ALLOCA_H
if yes.
2. in code
#ifdef HAVE_ALLOCA_H
# include <alloca.h>
# define xalloca(size) (alloca(size))
# define xalloca_free(p) do {} while(0)
#else
# define xalloca(size) (xmalloc(size))
# define xalloca_free(p) (free(p))
#endif
and use it like
func() {
p = xalloca(size);
...
xalloca_free(p);
}
This way, for systems, where alloca is available, we'll have optimal
on-stack allocations with fast executions. On the other hand, on
systems, where alloca is not available, this gracefully fallbacks to
xmalloc/free.
Both autoconf and config.mak.uname configurations were updated. For
autoconf, we are not bothering considering cases, when no alloca.h is
available, but alloca() works some other way - its simply alloca.h is
available and works or not, everything else is deep legacy.
For config.mak.uname, I've tried to make my almost-sure guess for where
alloca() is available, but since I only have access to Linux it is the
only change I can be sure about myself, with relevant to other changed
systems people Cc'ed.
NOTE
SunOS and Windows had explicit -DHAVE_ALLOCA_H in their configurations.
I've changed that to now-common HAVE_ALLOCA_H=YesPlease which should be
correct.
Cc: Brandon Casey <drafnel@gmail.com>
Cc: Marius Storm-Olsen <mstormo@gmail.com>
Cc: Johannes Sixt <j6t@kdbg.org>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Cc: Gerrit Pape <pape@smarden.org>
Cc: Petr Salinger <Petr.Salinger@seznam.cz>
Cc: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Thomas Schwinge <thomas@codesourcery.com> (GNU Hurd changes)
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-27 18:22:50 +04:00
|
|
|
BASIC_CFLAGS += -D__EXTENSIONS__ -D__sun__
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_O),Cygwin)
|
|
|
|
|
ifeq ($(shell expr "$(uname_R)" : '1\.[1-6]\.'),4)
|
|
|
|
|
NO_D_TYPE_IN_DIRENT = YesPlease
|
|
|
|
|
NO_STRCASESTR = YesPlease
|
|
|
|
|
NO_MEMMEM = YesPlease
|
|
|
|
|
NO_SYMLINK_HEAD = YesPlease
|
|
|
|
|
NO_IPV6 = YesPlease
|
|
|
|
|
OLD_ICONV = UnfortunatelyYes
|
2013-07-20 03:08:30 +04:00
|
|
|
# There are conflicting reports about this.
|
|
|
|
|
# On some boxes NO_MMAP is needed, and not so elsewhere.
|
|
|
|
|
# Try commenting this out if you suspect MMAP is more efficient
|
|
|
|
|
NO_MMAP = YesPlease
|
2013-07-20 03:08:28 +04:00
|
|
|
else
|
|
|
|
|
NO_REGEX = UnfortunatelyYes
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
endif
|
Portable alloca for Git
In the next patch we'll have to use alloca() for performance reasons,
but since alloca is non-standardized and is not portable, let's have a
trick with compatibility wrappers:
1. at configure time, determine, do we have working alloca() through
alloca.h, and define
#define HAVE_ALLOCA_H
if yes.
2. in code
#ifdef HAVE_ALLOCA_H
# include <alloca.h>
# define xalloca(size) (alloca(size))
# define xalloca_free(p) do {} while(0)
#else
# define xalloca(size) (xmalloc(size))
# define xalloca_free(p) (free(p))
#endif
and use it like
func() {
p = xalloca(size);
...
xalloca_free(p);
}
This way, for systems, where alloca is available, we'll have optimal
on-stack allocations with fast executions. On the other hand, on
systems, where alloca is not available, this gracefully fallbacks to
xmalloc/free.
Both autoconf and config.mak.uname configurations were updated. For
autoconf, we are not bothering considering cases, when no alloca.h is
available, but alloca() works some other way - its simply alloca.h is
available and works or not, everything else is deep legacy.
For config.mak.uname, I've tried to make my almost-sure guess for where
alloca() is available, but since I only have access to Linux it is the
only change I can be sure about myself, with relevant to other changed
systems people Cc'ed.
NOTE
SunOS and Windows had explicit -DHAVE_ALLOCA_H in their configurations.
I've changed that to now-common HAVE_ALLOCA_H=YesPlease which should be
correct.
Cc: Brandon Casey <drafnel@gmail.com>
Cc: Marius Storm-Olsen <mstormo@gmail.com>
Cc: Johannes Sixt <j6t@kdbg.org>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Cc: Gerrit Pape <pape@smarden.org>
Cc: Petr Salinger <Petr.Salinger@seznam.cz>
Cc: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Thomas Schwinge <thomas@codesourcery.com> (GNU Hurd changes)
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-27 18:22:50 +04:00
|
|
|
HAVE_ALLOCA_H = YesPlease
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
NEEDS_LIBICONV = YesPlease
|
|
|
|
|
NO_FAST_WORKING_DIRECTORY = UnfortunatelyYes
|
|
|
|
|
NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
|
|
|
|
|
X = .exe
|
|
|
|
|
UNRELIABLE_FSTAT = UnfortunatelyYes
|
2015-08-07 23:30:28 +03:00
|
|
|
OBJECT_CREATION_USES_RENAMES = UnfortunatelyNeedsTo
|
2017-09-25 11:00:10 +03:00
|
|
|
MMAP_PREVENTS_DELETE = UnfortunatelyYes
|
2018-12-15 07:33:30 +03:00
|
|
|
COMPAT_OBJS += compat/win32/path-utils.o
|
2017-07-21 21:43:17 +03:00
|
|
|
FREAD_READS_DIRECTORIES = UnfortunatelyYes
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_S),FreeBSD)
|
|
|
|
|
NEEDS_LIBICONV = YesPlease
|
2018-08-31 11:33:42 +03:00
|
|
|
# Versions up to 10.1 require OLD_ICONV; 10.2 and beyond don't.
|
|
|
|
|
# A typical version string looks like "10.2-RELEASE".
|
|
|
|
|
ifeq ($(shell expr "$(uname_R)" : '[1-9]\.'),2)
|
|
|
|
|
OLD_ICONV = YesPlease
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(firstword $(subst -, ,$(uname_R))),10.0)
|
|
|
|
|
OLD_ICONV = YesPlease
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(firstword $(subst -, ,$(uname_R))),10.1)
|
|
|
|
|
OLD_ICONV = YesPlease
|
|
|
|
|
endif
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
NO_MEMMEM = YesPlease
|
|
|
|
|
BASIC_CFLAGS += -I/usr/local/include
|
|
|
|
|
BASIC_LDFLAGS += -L/usr/local/lib
|
|
|
|
|
DIR_HAS_BSD_GROUP_SEMANTICS = YesPlease
|
|
|
|
|
USE_ST_TIMESPEC = YesPlease
|
|
|
|
|
ifeq ($(shell expr "$(uname_R)" : '4\.'),2)
|
|
|
|
|
PTHREAD_LIBS = -pthread
|
|
|
|
|
NO_UINTMAX_T = YesPlease
|
|
|
|
|
NO_STRTOUMAX = YesPlease
|
|
|
|
|
endif
|
|
|
|
|
PYTHON_PATH = /usr/local/bin/python
|
2016-07-25 19:21:25 +03:00
|
|
|
PERL_PATH = /usr/local/bin/perl
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
HAVE_PATHS_H = YesPlease
|
2015-03-08 10:14:36 +03:00
|
|
|
HAVE_BSD_SYSCTL = YesPlease
|
2018-04-10 18:05:44 +03:00
|
|
|
HAVE_BSD_KERN_PROC_SYSCTL = YesPlease
|
wrapper: add a helper to generate numbers from a CSPRNG
There are many situations in which having access to a cryptographically
secure pseudorandom number generator (CSPRNG) is helpful. In the
future, we'll encounter one of these when dealing with temporary files.
To make this possible, let's add a function which reads from a system
CSPRNG and returns some bytes.
We know that all systems will have such an interface. A CSPRNG is
required for a secure TLS or SSH implementation and a Git implementation
which provided neither would be of little practical use. In addition,
POSIX is set to standardize getentropy(2) in the next version, so in the
(potentially distant) future we can rely on that.
For systems which lack one of the other interfaces, we provide the
ability to use OpenSSL's CSPRNG. OpenSSL is highly portable and
functions on practically every known OS, and we know it will have access
to some source of cryptographically secure randomness. We also provide
support for the arc4random in libbsd for folks who would prefer to use
that.
Because this is a security sensitive interface, we take some
precautions. We either succeed by filling the buffer completely as we
requested, or we fail. We don't return partial data because the caller
will almost never find that to be a useful behavior.
Specify a makefile knob which users can use to specify one or more
suitable CSPRNGs, and turn the multiple string options into a set of
defines, since we cannot match on strings in the preprocessor. We allow
multiple options to make the job of handling this in autoconf easier.
The order of options is important here. On systems with arc4random,
which is most of the BSDs, we use that, since, except on MirBSD and
macOS, it uses ChaCha20, which is extremely fast, and sits entirely in
userspace, avoiding a system call. We then prefer getrandom over
getentropy, because the former has been available longer on Linux, and
then OpenSSL. Finally, if none of those are available, we use
/dev/urandom, because most Unix-like operating systems provide that API.
We prefer options that don't involve device files when possible because
those work in some restricted environments where device files may not be
available.
Set the configuration variables appropriately for Linux and the BSDs,
including macOS, as well as Windows and NonStop. We specifically only
consider versions which receive publicly available security support
here. For the same reason, we don't specify getrandom(2) on Linux,
because CentOS 7 doesn't support it in glibc (although its kernel does)
and we don't want to resort to making syscalls.
Finally, add a test helper to allow this to be tested by hand and in
tests. We don't add any tests, since invoking the CSPRNG is not likely
to produce interesting, reproducible results.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-18 00:56:16 +03:00
|
|
|
CSPRNG_METHOD = arc4random
|
2016-08-04 14:40:25 +03:00
|
|
|
PAGER_ENV = LESS=FRX LV=-c MORE=FRX
|
2017-05-03 13:16:48 +03:00
|
|
|
FREAD_READS_DIRECTORIES = UnfortunatelyYes
|
2019-02-12 17:14:41 +03:00
|
|
|
FILENO_IS_A_MACRO = UnfortunatelyYes
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_S),OpenBSD)
|
|
|
|
|
NO_STRCASESTR = YesPlease
|
|
|
|
|
NO_MEMMEM = YesPlease
|
|
|
|
|
USE_ST_TIMESPEC = YesPlease
|
|
|
|
|
NEEDS_LIBICONV = YesPlease
|
|
|
|
|
BASIC_CFLAGS += -I/usr/local/include
|
|
|
|
|
BASIC_LDFLAGS += -L/usr/local/lib
|
|
|
|
|
HAVE_PATHS_H = YesPlease
|
2015-03-08 10:14:36 +03:00
|
|
|
HAVE_BSD_SYSCTL = YesPlease
|
2018-04-10 18:05:44 +03:00
|
|
|
HAVE_BSD_KERN_PROC_SYSCTL = YesPlease
|
wrapper: add a helper to generate numbers from a CSPRNG
There are many situations in which having access to a cryptographically
secure pseudorandom number generator (CSPRNG) is helpful. In the
future, we'll encounter one of these when dealing with temporary files.
To make this possible, let's add a function which reads from a system
CSPRNG and returns some bytes.
We know that all systems will have such an interface. A CSPRNG is
required for a secure TLS or SSH implementation and a Git implementation
which provided neither would be of little practical use. In addition,
POSIX is set to standardize getentropy(2) in the next version, so in the
(potentially distant) future we can rely on that.
For systems which lack one of the other interfaces, we provide the
ability to use OpenSSL's CSPRNG. OpenSSL is highly portable and
functions on practically every known OS, and we know it will have access
to some source of cryptographically secure randomness. We also provide
support for the arc4random in libbsd for folks who would prefer to use
that.
Because this is a security sensitive interface, we take some
precautions. We either succeed by filling the buffer completely as we
requested, or we fail. We don't return partial data because the caller
will almost never find that to be a useful behavior.
Specify a makefile knob which users can use to specify one or more
suitable CSPRNGs, and turn the multiple string options into a set of
defines, since we cannot match on strings in the preprocessor. We allow
multiple options to make the job of handling this in autoconf easier.
The order of options is important here. On systems with arc4random,
which is most of the BSDs, we use that, since, except on MirBSD and
macOS, it uses ChaCha20, which is extremely fast, and sits entirely in
userspace, avoiding a system call. We then prefer getrandom over
getentropy, because the former has been available longer on Linux, and
then OpenSSL. Finally, if none of those are available, we use
/dev/urandom, because most Unix-like operating systems provide that API.
We prefer options that don't involve device files when possible because
those work in some restricted environments where device files may not be
available.
Set the configuration variables appropriately for Linux and the BSDs,
including macOS, as well as Windows and NonStop. We specifically only
consider versions which receive publicly available security support
here. For the same reason, we don't specify getrandom(2) on Linux,
because CentOS 7 doesn't support it in glibc (although its kernel does)
and we don't want to resort to making syscalls.
Finally, add a test helper to allow this to be tested by hand and in
tests. We don't add any tests, since invoking the CSPRNG is not likely
to produce interesting, reproducible results.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-18 00:56:16 +03:00
|
|
|
CSPRNG_METHOD = arc4random
|
2018-04-10 18:05:44 +03:00
|
|
|
PROCFS_EXECUTABLE_PATH = /proc/curproc/file
|
2018-12-02 05:43:20 +03:00
|
|
|
FREAD_READS_DIRECTORIES = UnfortunatelyYes
|
2019-02-12 17:14:41 +03:00
|
|
|
FILENO_IS_A_MACRO = UnfortunatelyYes
|
2013-12-31 18:36:45 +04:00
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_S),MirBSD)
|
|
|
|
|
NO_STRCASESTR = YesPlease
|
|
|
|
|
NO_MEMMEM = YesPlease
|
|
|
|
|
USE_ST_TIMESPEC = YesPlease
|
|
|
|
|
NEEDS_LIBICONV = YesPlease
|
|
|
|
|
HAVE_PATHS_H = YesPlease
|
2015-03-08 10:14:36 +03:00
|
|
|
HAVE_BSD_SYSCTL = YesPlease
|
wrapper: add a helper to generate numbers from a CSPRNG
There are many situations in which having access to a cryptographically
secure pseudorandom number generator (CSPRNG) is helpful. In the
future, we'll encounter one of these when dealing with temporary files.
To make this possible, let's add a function which reads from a system
CSPRNG and returns some bytes.
We know that all systems will have such an interface. A CSPRNG is
required for a secure TLS or SSH implementation and a Git implementation
which provided neither would be of little practical use. In addition,
POSIX is set to standardize getentropy(2) in the next version, so in the
(potentially distant) future we can rely on that.
For systems which lack one of the other interfaces, we provide the
ability to use OpenSSL's CSPRNG. OpenSSL is highly portable and
functions on practically every known OS, and we know it will have access
to some source of cryptographically secure randomness. We also provide
support for the arc4random in libbsd for folks who would prefer to use
that.
Because this is a security sensitive interface, we take some
precautions. We either succeed by filling the buffer completely as we
requested, or we fail. We don't return partial data because the caller
will almost never find that to be a useful behavior.
Specify a makefile knob which users can use to specify one or more
suitable CSPRNGs, and turn the multiple string options into a set of
defines, since we cannot match on strings in the preprocessor. We allow
multiple options to make the job of handling this in autoconf easier.
The order of options is important here. On systems with arc4random,
which is most of the BSDs, we use that, since, except on MirBSD and
macOS, it uses ChaCha20, which is extremely fast, and sits entirely in
userspace, avoiding a system call. We then prefer getrandom over
getentropy, because the former has been available longer on Linux, and
then OpenSSL. Finally, if none of those are available, we use
/dev/urandom, because most Unix-like operating systems provide that API.
We prefer options that don't involve device files when possible because
those work in some restricted environments where device files may not be
available.
Set the configuration variables appropriately for Linux and the BSDs,
including macOS, as well as Windows and NonStop. We specifically only
consider versions which receive publicly available security support
here. For the same reason, we don't specify getrandom(2) on Linux,
because CentOS 7 doesn't support it in glibc (although its kernel does)
and we don't want to resort to making syscalls.
Finally, add a test helper to allow this to be tested by hand and in
tests. We don't add any tests, since invoking the CSPRNG is not likely
to produce interesting, reproducible results.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-18 00:56:16 +03:00
|
|
|
CSPRNG_METHOD = arc4random
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_S),NetBSD)
|
|
|
|
|
ifeq ($(shell expr "$(uname_R)" : '[01]\.'),2)
|
|
|
|
|
NEEDS_LIBICONV = YesPlease
|
|
|
|
|
endif
|
|
|
|
|
BASIC_CFLAGS += -I/usr/pkg/include
|
|
|
|
|
BASIC_LDFLAGS += -L/usr/pkg/lib $(CC_LD_DYNPATH)/usr/pkg/lib
|
|
|
|
|
USE_ST_TIMESPEC = YesPlease
|
|
|
|
|
HAVE_PATHS_H = YesPlease
|
2015-03-08 10:14:36 +03:00
|
|
|
HAVE_BSD_SYSCTL = YesPlease
|
2018-04-10 18:05:44 +03:00
|
|
|
HAVE_BSD_KERN_PROC_SYSCTL = YesPlease
|
wrapper: add a helper to generate numbers from a CSPRNG
There are many situations in which having access to a cryptographically
secure pseudorandom number generator (CSPRNG) is helpful. In the
future, we'll encounter one of these when dealing with temporary files.
To make this possible, let's add a function which reads from a system
CSPRNG and returns some bytes.
We know that all systems will have such an interface. A CSPRNG is
required for a secure TLS or SSH implementation and a Git implementation
which provided neither would be of little practical use. In addition,
POSIX is set to standardize getentropy(2) in the next version, so in the
(potentially distant) future we can rely on that.
For systems which lack one of the other interfaces, we provide the
ability to use OpenSSL's CSPRNG. OpenSSL is highly portable and
functions on practically every known OS, and we know it will have access
to some source of cryptographically secure randomness. We also provide
support for the arc4random in libbsd for folks who would prefer to use
that.
Because this is a security sensitive interface, we take some
precautions. We either succeed by filling the buffer completely as we
requested, or we fail. We don't return partial data because the caller
will almost never find that to be a useful behavior.
Specify a makefile knob which users can use to specify one or more
suitable CSPRNGs, and turn the multiple string options into a set of
defines, since we cannot match on strings in the preprocessor. We allow
multiple options to make the job of handling this in autoconf easier.
The order of options is important here. On systems with arc4random,
which is most of the BSDs, we use that, since, except on MirBSD and
macOS, it uses ChaCha20, which is extremely fast, and sits entirely in
userspace, avoiding a system call. We then prefer getrandom over
getentropy, because the former has been available longer on Linux, and
then OpenSSL. Finally, if none of those are available, we use
/dev/urandom, because most Unix-like operating systems provide that API.
We prefer options that don't involve device files when possible because
those work in some restricted environments where device files may not be
available.
Set the configuration variables appropriately for Linux and the BSDs,
including macOS, as well as Windows and NonStop. We specifically only
consider versions which receive publicly available security support
here. For the same reason, we don't specify getrandom(2) on Linux,
because CentOS 7 doesn't support it in glibc (although its kernel does)
and we don't want to resort to making syscalls.
Finally, add a test helper to allow this to be tested by hand and in
tests. We don't add any tests, since invoking the CSPRNG is not likely
to produce interesting, reproducible results.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-18 00:56:16 +03:00
|
|
|
CSPRNG_METHOD = arc4random
|
2018-04-10 18:05:44 +03:00
|
|
|
PROCFS_EXECUTABLE_PATH = /proc/curproc/exe
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_S),AIX)
|
|
|
|
|
DEFAULT_PAGER = more
|
|
|
|
|
NO_STRCASESTR = YesPlease
|
|
|
|
|
NO_MEMMEM = YesPlease
|
|
|
|
|
NO_MKDTEMP = YesPlease
|
|
|
|
|
NO_STRLCPY = YesPlease
|
|
|
|
|
NO_NSEC = YesPlease
|
2017-05-03 16:54:30 +03:00
|
|
|
NO_REGEX = NeedsStartEnd
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
FREAD_READS_DIRECTORIES = UnfortunatelyYes
|
|
|
|
|
INTERNAL_QSORT = UnfortunatelyYes
|
|
|
|
|
NEEDS_LIBICONV = YesPlease
|
|
|
|
|
BASIC_CFLAGS += -D_LARGE_FILES
|
2019-04-18 11:55:09 +03:00
|
|
|
FILENO_IS_A_MACRO = UnfortunatelyYes
|
2019-04-25 10:01:56 +03:00
|
|
|
NEED_ACCESS_ROOT_HANDLER = UnfortunatelyYes
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
ifeq ($(shell expr "$(uname_V)" : '[1234]'),1)
|
|
|
|
|
NO_PTHREADS = YesPlease
|
|
|
|
|
else
|
|
|
|
|
PTHREAD_LIBS = -lpthread
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(shell expr "$(uname_V).$(uname_R)" : '5\.1'),3)
|
|
|
|
|
INLINE = ''
|
|
|
|
|
endif
|
|
|
|
|
GIT_TEST_CMP = cmp
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_S),GNU)
|
|
|
|
|
# GNU/Hurd
|
Portable alloca for Git
In the next patch we'll have to use alloca() for performance reasons,
but since alloca is non-standardized and is not portable, let's have a
trick with compatibility wrappers:
1. at configure time, determine, do we have working alloca() through
alloca.h, and define
#define HAVE_ALLOCA_H
if yes.
2. in code
#ifdef HAVE_ALLOCA_H
# include <alloca.h>
# define xalloca(size) (alloca(size))
# define xalloca_free(p) do {} while(0)
#else
# define xalloca(size) (xmalloc(size))
# define xalloca_free(p) (free(p))
#endif
and use it like
func() {
p = xalloca(size);
...
xalloca_free(p);
}
This way, for systems, where alloca is available, we'll have optimal
on-stack allocations with fast executions. On the other hand, on
systems, where alloca is not available, this gracefully fallbacks to
xmalloc/free.
Both autoconf and config.mak.uname configurations were updated. For
autoconf, we are not bothering considering cases, when no alloca.h is
available, but alloca() works some other way - its simply alloca.h is
available and works or not, everything else is deep legacy.
For config.mak.uname, I've tried to make my almost-sure guess for where
alloca() is available, but since I only have access to Linux it is the
only change I can be sure about myself, with relevant to other changed
systems people Cc'ed.
NOTE
SunOS and Windows had explicit -DHAVE_ALLOCA_H in their configurations.
I've changed that to now-common HAVE_ALLOCA_H=YesPlease which should be
correct.
Cc: Brandon Casey <drafnel@gmail.com>
Cc: Marius Storm-Olsen <mstormo@gmail.com>
Cc: Johannes Sixt <j6t@kdbg.org>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Cc: Gerrit Pape <pape@smarden.org>
Cc: Petr Salinger <Petr.Salinger@seznam.cz>
Cc: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Thomas Schwinge <thomas@codesourcery.com> (GNU Hurd changes)
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-27 18:22:50 +04:00
|
|
|
HAVE_ALLOCA_H = YesPlease
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
NO_STRLCPY = YesPlease
|
|
|
|
|
HAVE_PATHS_H = YesPlease
|
|
|
|
|
LIBC_CONTAINS_LIBINTL = YesPlease
|
2020-04-22 18:33:47 +03:00
|
|
|
FREAD_READS_DIRECTORIES = UnfortunatelyYes
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_S),IRIX)
|
|
|
|
|
NO_SETENV = YesPlease
|
|
|
|
|
NO_UNSETENV = YesPlease
|
|
|
|
|
NO_STRCASESTR = YesPlease
|
|
|
|
|
NO_MEMMEM = YesPlease
|
|
|
|
|
NO_MKDTEMP = YesPlease
|
|
|
|
|
# When compiled with the MIPSpro 7.4.4m compiler, and without pthreads
|
|
|
|
|
# (i.e. NO_PTHREADS is set), and _with_ MMAP (i.e. NO_MMAP is not set),
|
|
|
|
|
# git dies with a segmentation fault when trying to access the first
|
|
|
|
|
# entry of a reflog. The conservative choice is made to always set
|
|
|
|
|
# NO_MMAP. If you suspect that your compiler is not affected by this
|
|
|
|
|
# issue, comment out the NO_MMAP statement.
|
|
|
|
|
NO_MMAP = YesPlease
|
|
|
|
|
NO_REGEX = YesPlease
|
|
|
|
|
SNPRINTF_RETURNS_BOGUS = YesPlease
|
|
|
|
|
SHELL_PATH = /usr/gnu/bin/bash
|
|
|
|
|
NEEDS_LIBGEN = YesPlease
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_S),IRIX64)
|
|
|
|
|
NO_SETENV = YesPlease
|
|
|
|
|
NO_UNSETENV = YesPlease
|
|
|
|
|
NO_STRCASESTR = YesPlease
|
|
|
|
|
NO_MEMMEM = YesPlease
|
|
|
|
|
NO_MKDTEMP = YesPlease
|
|
|
|
|
# When compiled with the MIPSpro 7.4.4m compiler, and without pthreads
|
|
|
|
|
# (i.e. NO_PTHREADS is set), and _with_ MMAP (i.e. NO_MMAP is not set),
|
|
|
|
|
# git dies with a segmentation fault when trying to access the first
|
|
|
|
|
# entry of a reflog. The conservative choice is made to always set
|
|
|
|
|
# NO_MMAP. If you suspect that your compiler is not affected by this
|
|
|
|
|
# issue, comment out the NO_MMAP statement.
|
|
|
|
|
NO_MMAP = YesPlease
|
|
|
|
|
NO_REGEX = YesPlease
|
|
|
|
|
SNPRINTF_RETURNS_BOGUS = YesPlease
|
|
|
|
|
SHELL_PATH = /usr/gnu/bin/bash
|
|
|
|
|
NEEDS_LIBGEN = YesPlease
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_S),HP-UX)
|
|
|
|
|
INLINE = __inline
|
|
|
|
|
NO_IPV6 = YesPlease
|
|
|
|
|
NO_SETENV = YesPlease
|
|
|
|
|
NO_STRCASESTR = YesPlease
|
|
|
|
|
NO_MEMMEM = YesPlease
|
|
|
|
|
NO_STRLCPY = YesPlease
|
|
|
|
|
NO_MKDTEMP = YesPlease
|
|
|
|
|
NO_UNSETENV = YesPlease
|
|
|
|
|
NO_HSTRERROR = YesPlease
|
|
|
|
|
NO_SYS_SELECT_H = YesPlease
|
|
|
|
|
SNPRINTF_RETURNS_BOGUS = YesPlease
|
|
|
|
|
NO_NSEC = YesPlease
|
|
|
|
|
ifeq ($(uname_R),B.11.00)
|
|
|
|
|
NO_INET_NTOP = YesPlease
|
|
|
|
|
NO_INET_PTON = YesPlease
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_R),B.10.20)
|
|
|
|
|
# Override HP-UX 11.x setting:
|
|
|
|
|
INLINE =
|
|
|
|
|
SOCKLEN_T = size_t
|
|
|
|
|
NO_PREAD = YesPlease
|
|
|
|
|
NO_INET_NTOP = YesPlease
|
|
|
|
|
NO_INET_PTON = YesPlease
|
|
|
|
|
endif
|
|
|
|
|
GIT_TEST_CMP = cmp
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_S),Windows)
|
|
|
|
|
GIT_VERSION := $(GIT_VERSION).MSVC
|
|
|
|
|
pathsep = ;
|
2019-06-25 17:49:39 +03:00
|
|
|
# Assume that this is built in Git for Windows' SDK
|
|
|
|
|
ifeq (MINGW32,$(MSYSTEM))
|
|
|
|
|
prefix = /mingw32
|
|
|
|
|
else
|
|
|
|
|
prefix = /mingw64
|
|
|
|
|
endif
|
|
|
|
|
# Prepend MSVC 64-bit tool-chain to PATH.
|
|
|
|
|
#
|
|
|
|
|
# A regular Git Bash *does not* have cl.exe in its $PATH. As there is a
|
|
|
|
|
# link.exe next to, and required by, cl.exe, we have to prepend this
|
|
|
|
|
# onto the existing $PATH.
|
|
|
|
|
#
|
|
|
|
|
SANE_TOOL_PATH ?= $(msvc_bin_dir_msys)
|
Portable alloca for Git
In the next patch we'll have to use alloca() for performance reasons,
but since alloca is non-standardized and is not portable, let's have a
trick with compatibility wrappers:
1. at configure time, determine, do we have working alloca() through
alloca.h, and define
#define HAVE_ALLOCA_H
if yes.
2. in code
#ifdef HAVE_ALLOCA_H
# include <alloca.h>
# define xalloca(size) (alloca(size))
# define xalloca_free(p) do {} while(0)
#else
# define xalloca(size) (xmalloc(size))
# define xalloca_free(p) (free(p))
#endif
and use it like
func() {
p = xalloca(size);
...
xalloca_free(p);
}
This way, for systems, where alloca is available, we'll have optimal
on-stack allocations with fast executions. On the other hand, on
systems, where alloca is not available, this gracefully fallbacks to
xmalloc/free.
Both autoconf and config.mak.uname configurations were updated. For
autoconf, we are not bothering considering cases, when no alloca.h is
available, but alloca() works some other way - its simply alloca.h is
available and works or not, everything else is deep legacy.
For config.mak.uname, I've tried to make my almost-sure guess for where
alloca() is available, but since I only have access to Linux it is the
only change I can be sure about myself, with relevant to other changed
systems people Cc'ed.
NOTE
SunOS and Windows had explicit -DHAVE_ALLOCA_H in their configurations.
I've changed that to now-common HAVE_ALLOCA_H=YesPlease which should be
correct.
Cc: Brandon Casey <drafnel@gmail.com>
Cc: Marius Storm-Olsen <mstormo@gmail.com>
Cc: Johannes Sixt <j6t@kdbg.org>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Cc: Gerrit Pape <pape@smarden.org>
Cc: Petr Salinger <Petr.Salinger@seznam.cz>
Cc: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Thomas Schwinge <thomas@codesourcery.com> (GNU Hurd changes)
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-27 18:22:50 +04:00
|
|
|
HAVE_ALLOCA_H = YesPlease
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
NO_PREAD = YesPlease
|
|
|
|
|
NEEDS_CRYPTO_WITH_SSL = YesPlease
|
|
|
|
|
NO_LIBGEN_H = YesPlease
|
|
|
|
|
NO_POLL = YesPlease
|
|
|
|
|
NO_SYMLINK_HEAD = YesPlease
|
|
|
|
|
NO_IPV6 = YesPlease
|
|
|
|
|
NO_UNIX_SOCKETS = YesPlease
|
|
|
|
|
NO_SETENV = YesPlease
|
|
|
|
|
NO_STRCASESTR = YesPlease
|
|
|
|
|
NO_STRLCPY = YesPlease
|
|
|
|
|
NO_MEMMEM = YesPlease
|
2019-06-25 17:49:39 +03:00
|
|
|
NEEDS_LIBICONV = YesPlease
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
NO_STRTOUMAX = YesPlease
|
|
|
|
|
NO_MKDTEMP = YesPlease
|
2019-06-25 17:49:39 +03:00
|
|
|
NO_INTTYPES_H = YesPlease
|
wrapper: add a helper to generate numbers from a CSPRNG
There are many situations in which having access to a cryptographically
secure pseudorandom number generator (CSPRNG) is helpful. In the
future, we'll encounter one of these when dealing with temporary files.
To make this possible, let's add a function which reads from a system
CSPRNG and returns some bytes.
We know that all systems will have such an interface. A CSPRNG is
required for a secure TLS or SSH implementation and a Git implementation
which provided neither would be of little practical use. In addition,
POSIX is set to standardize getentropy(2) in the next version, so in the
(potentially distant) future we can rely on that.
For systems which lack one of the other interfaces, we provide the
ability to use OpenSSL's CSPRNG. OpenSSL is highly portable and
functions on practically every known OS, and we know it will have access
to some source of cryptographically secure randomness. We also provide
support for the arc4random in libbsd for folks who would prefer to use
that.
Because this is a security sensitive interface, we take some
precautions. We either succeed by filling the buffer completely as we
requested, or we fail. We don't return partial data because the caller
will almost never find that to be a useful behavior.
Specify a makefile knob which users can use to specify one or more
suitable CSPRNGs, and turn the multiple string options into a set of
defines, since we cannot match on strings in the preprocessor. We allow
multiple options to make the job of handling this in autoconf easier.
The order of options is important here. On systems with arc4random,
which is most of the BSDs, we use that, since, except on MirBSD and
macOS, it uses ChaCha20, which is extremely fast, and sits entirely in
userspace, avoiding a system call. We then prefer getrandom over
getentropy, because the former has been available longer on Linux, and
then OpenSSL. Finally, if none of those are available, we use
/dev/urandom, because most Unix-like operating systems provide that API.
We prefer options that don't involve device files when possible because
those work in some restricted environments where device files may not be
available.
Set the configuration variables appropriately for Linux and the BSDs,
including macOS, as well as Windows and NonStop. We specifically only
consider versions which receive publicly available security support
here. For the same reason, we don't specify getrandom(2) on Linux,
because CentOS 7 doesn't support it in glibc (although its kernel does)
and we don't want to resort to making syscalls.
Finally, add a test helper to allow this to be tested by hand and in
tests. We don't add any tests, since invoking the CSPRNG is not likely
to produce interesting, reproducible results.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-18 00:56:16 +03:00
|
|
|
CSPRNG_METHOD = rtlgenrandom
|
2019-06-25 17:49:39 +03:00
|
|
|
# VS2015 with UCRT claims that snprintf and friends are C99 compliant,
|
|
|
|
|
# so we don't need this:
|
|
|
|
|
#
|
|
|
|
|
# SNPRINTF_RETURNS_BOGUS = YesPlease
|
2022-03-25 21:02:51 +03:00
|
|
|
|
|
|
|
|
# The builtin FSMonitor requires Named Pipes and Threads on Windows.
|
|
|
|
|
# These are always available, so we do not have to conditionally
|
|
|
|
|
# support it.
|
|
|
|
|
FSMONITOR_DAEMON_BACKEND = win32
|
2022-05-27 00:46:59 +03:00
|
|
|
FSMONITOR_OS_SETTINGS = win32
|
|
|
|
|
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
NO_SVN_TESTS = YesPlease
|
|
|
|
|
RUNTIME_PREFIX = YesPlease
|
2018-04-10 18:05:46 +03:00
|
|
|
HAVE_WPGMPTR = YesWeDo
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
|
2021-03-16 00:08:23 +03:00
|
|
|
USE_WIN32_IPC = YesPlease
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
USE_WIN32_MMAP = YesPlease
|
2017-09-25 11:00:10 +03:00
|
|
|
MMAP_PREVENTS_DELETE = UnfortunatelyYes
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
# USE_NED_ALLOCATOR = YesPlease
|
|
|
|
|
UNRELIABLE_FSTAT = UnfortunatelyYes
|
|
|
|
|
OBJECT_CREATION_USES_RENAMES = UnfortunatelyNeedsTo
|
|
|
|
|
NO_REGEX = YesPlease
|
2013-09-11 03:21:53 +04:00
|
|
|
NO_GETTEXT = YesPlease
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
NO_PYTHON = YesPlease
|
2013-01-31 22:33:57 +04:00
|
|
|
ETAGS_TARGET = ETAGS
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
NO_POSIX_GOODIES = UnfortunatelyYes
|
|
|
|
|
NATIVE_CRLF = YesPlease
|
|
|
|
|
DEFAULT_HELP_FORMAT = html
|
mingw: move Git for Windows' system config where users expect it
Git for Windows' prefix is `/mingw64/` (or `/mingw32/` for 32-bit
versions), therefore the system config is located at the clunky location
`C:\Program Files\Git\mingw64\etc\gitconfig`.
This moves the system config into a more logical location: the `mingw64`
part of `C:\Program Files\Git\mingw64\etc\gitconfig` never made sense,
as it is a mere implementation detail. Let's skip the `mingw64` part and
move this to `C:\Program Files\Git\etc\gitconfig`.
Side note: in the rare (and not recommended) case a user chooses to
install 32-bit Git for Windows on a 64-bit system, the path will of
course be `C:\Program Files (x86)\Git\etc\gitconfig`.
Background: During the Git for Windows v1.x days, the system config was
located at `C:\Program Files (x86)\Git\etc\gitconfig`. With Git for
Windows v2.x, it moved to `C:\Program Files\Git\mingw64\gitconfig` (or
`C:\Program Files (x86)\Git\mingw32\gitconfig`). Rather than fixing it
back then, we tried to introduce a "Windows-wide" config, but that never
caught on.
Likewise, we move the system `gitattributes` into the same directory.
Obviously, we are cautious to do this only for the known install
locations `/mingw64` and `/mingw32`; If anybody wants to override that
while building their version of Git (e.g. via `make prefix=$HOME`), we
leave the default location of the system config and gitattributes alone.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-06-22 13:46:46 +03:00
|
|
|
ifeq (/mingw64,$(subst 32,64,$(prefix)))
|
|
|
|
|
# Move system config into top-level /etc/
|
|
|
|
|
ETC_GITCONFIG = ../etc/gitconfig
|
|
|
|
|
ETC_GITATTRIBUTES = ../etc/gitattributes
|
|
|
|
|
endif
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
|
|
|
|
|
CC = compat/vcbuild/scripts/clink.pl
|
|
|
|
|
AR = compat/vcbuild/scripts/lib.pl
|
|
|
|
|
CFLAGS =
|
2019-06-25 17:49:39 +03:00
|
|
|
BASIC_CFLAGS = -nologo -I. -Icompat/vcbuild/include -DWIN32 -D_CONSOLE -DHAVE_STRING_H -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
COMPAT_OBJS = compat/msvc.o compat/winansi.o \
|
2022-03-11 01:43:20 +03:00
|
|
|
compat/win32/flush.o \
|
2019-04-08 14:26:16 +03:00
|
|
|
compat/win32/path-utils.o \
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
compat/win32/pthread.o compat/win32/syslog.o \
|
2019-02-23 01:25:02 +03:00
|
|
|
compat/win32/trace2_win32_process_info.o \
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
compat/win32/dirent.o
|
2019-06-25 17:49:39 +03:00
|
|
|
COMPAT_CFLAGS = -D__USE_MINGW_ACCESS -DDETECT_MSYS_TTY -DNOGDI -DHAVE_STRING_H -Icompat -Icompat/regex -Icompat/win32 -DSTRIP_EXTENSION=\".exe\"
|
mingw: replace mingw_startup() hack
Git for Windows has special code to retrieve the command-line parameters
(and even the environment) in UTF-16 encoding, so that they can be
converted to UTF-8. This is necessary because Git for Windows wants to
use UTF-8 encoded strings throughout its code, and the main() function
does not get the parameters in that encoding.
To do that, we used the __wgetmainargs() function, which is not even a
Win32 API function, but provided by the MINGW "runtime" instead.
Obviously, this method would not work with any compiler other than GCC,
and in preparation for compiling with Visual C++, we would like to avoid
precisely that.
Lucky us, there is a much more elegant way: we can simply implement the
UTF-16 variant of `main()`: `wmain()`.
To make that work, we need to link with -municode. The command-line
parameters are passed to `wmain()` encoded in UTF-16, as desired, and
this method also works with GCC, and also with Visual C++ after
adjusting the MSVC linker flags to force it to use `wmain()`.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-20 00:05:59 +03:00
|
|
|
BASIC_LDFLAGS = -IGNORE:4217 -IGNORE:4049 -NOLOGO -ENTRY:wmainCRTStartup -SUBSYSTEM:CONSOLE
|
2019-06-25 17:49:39 +03:00
|
|
|
# invalidcontinue.obj allows Git's source code to close the same file
|
|
|
|
|
# handle twice, or to access the osfhandle of an already-closed stdout
|
|
|
|
|
# See https://msdn.microsoft.com/en-us/library/ms235330.aspx
|
|
|
|
|
EXTLIBS = user32.lib advapi32.lib shell32.lib wininet.lib ws2_32.lib invalidcontinue.obj kernel32.lib ntdll.lib
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
PTHREAD_LIBS =
|
|
|
|
|
lib =
|
2019-06-25 17:49:39 +03:00
|
|
|
BASIC_CFLAGS += $(vcpkg_inc) $(sdk_includes) $(msvc_includes)
|
|
|
|
|
ifndef DEBUG
|
|
|
|
|
BASIC_CFLAGS += $(vcpkg_rel_lib)
|
|
|
|
|
else
|
|
|
|
|
BASIC_CFLAGS += $(vcpkg_dbg_lib)
|
|
|
|
|
endif
|
|
|
|
|
BASIC_CFLAGS += $(sdk_libs) $(msvc_libs)
|
|
|
|
|
|
2019-06-25 17:49:40 +03:00
|
|
|
ifneq ($(USE_MSVC_CRTDBG),)
|
|
|
|
|
# Optionally enable memory leak reporting.
|
|
|
|
|
BASIC_CFLAGS += -DUSE_MSVC_CRTDBG
|
|
|
|
|
endif
|
2019-06-25 17:49:39 +03:00
|
|
|
# Always give "-Zi" to the compiler and "-debug" to linker (even in
|
|
|
|
|
# release mode) to force a PDB to be generated (like RelWithDebInfo).
|
|
|
|
|
BASIC_CFLAGS += -Zi
|
|
|
|
|
BASIC_LDFLAGS += -debug -Zf
|
|
|
|
|
|
|
|
|
|
ifdef NO_SAFESEH
|
|
|
|
|
LDFLAGS += -SAFESEH:NO
|
|
|
|
|
endif
|
|
|
|
|
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
ifndef DEBUG
|
2019-06-25 17:49:39 +03:00
|
|
|
BASIC_CFLAGS += -GL -Gy -O2 -Oy- -MD -DNDEBUG
|
|
|
|
|
BASIC_LDFLAGS += -release -LTCG /OPT:REF /OPT:ICF /INCREMENTAL:NO /DEBUGTYPE:CV,FIXUP
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
AR += -LTCG
|
|
|
|
|
else
|
2019-06-25 17:49:39 +03:00
|
|
|
BASIC_CFLAGS += -MDd -DDEBUG -D_DEBUG
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
endif
|
|
|
|
|
X = .exe
|
2019-06-20 00:06:00 +03:00
|
|
|
|
|
|
|
|
compat/msvc.o: compat/msvc.c compat/mingw.c GIT-CFLAGS
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_S),Interix)
|
|
|
|
|
NO_INITGROUPS = YesPlease
|
|
|
|
|
NO_IPV6 = YesPlease
|
|
|
|
|
NO_MEMMEM = YesPlease
|
|
|
|
|
NO_MKDTEMP = YesPlease
|
|
|
|
|
NO_STRTOUMAX = YesPlease
|
|
|
|
|
NO_NSEC = YesPlease
|
|
|
|
|
ifeq ($(uname_R),3.5)
|
|
|
|
|
NO_INET_NTOP = YesPlease
|
|
|
|
|
NO_INET_PTON = YesPlease
|
|
|
|
|
NO_SOCKADDR_STORAGE = YesPlease
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_R),5.2)
|
|
|
|
|
NO_INET_NTOP = YesPlease
|
|
|
|
|
NO_INET_PTON = YesPlease
|
|
|
|
|
NO_SOCKADDR_STORAGE = YesPlease
|
|
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_S),Minix)
|
|
|
|
|
NO_IPV6 = YesPlease
|
|
|
|
|
NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
|
|
|
|
|
NO_NSEC = YesPlease
|
|
|
|
|
NEEDS_LIBGEN =
|
|
|
|
|
NEEDS_CRYPTO_WITH_SSL = YesPlease
|
|
|
|
|
NEEDS_RESOLV =
|
|
|
|
|
NO_HSTRERROR = YesPlease
|
|
|
|
|
NO_MMAP = YesPlease
|
|
|
|
|
NO_CURL =
|
|
|
|
|
NO_EXPAT =
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_S),NONSTOP_KERNEL)
|
|
|
|
|
# Needs some C99 features, "inline" is just one of them.
|
|
|
|
|
# INLINE='' would just replace one set of warnings with another and
|
|
|
|
|
# still not compile in c89 mode, due to non-const array initializations.
|
|
|
|
|
CC = cc -c99
|
2019-01-04 00:03:49 +03:00
|
|
|
# Build down-rev compatible objects that don't use our new getopt_long.
|
|
|
|
|
ifeq ($(uname_R).$(uname_V),J06.21)
|
|
|
|
|
CC += -WRVU=J06.20
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_R).$(uname_V),L17.02)
|
|
|
|
|
CC += -WRVU=L16.05
|
|
|
|
|
endif
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
# Disable all optimization, seems to result in bad code, with -O or -O2
|
|
|
|
|
# or even -O1 (default), /usr/local/libexec/git-core/git-pack-objects
|
|
|
|
|
# abends on "git push". Needs more investigation.
|
2019-01-04 00:03:49 +03:00
|
|
|
CFLAGS = -g -O0 -Winline
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
# We'd want it to be here.
|
|
|
|
|
prefix = /usr/local
|
2019-01-04 00:03:49 +03:00
|
|
|
# perl and python must be in /usr/bin on NonStop - supplied by HPE
|
|
|
|
|
# with operating system in that managed directory.
|
|
|
|
|
PERL_PATH = /usr/bin/perl
|
|
|
|
|
PYTHON_PATH = /usr/bin/python
|
|
|
|
|
# The current /usr/coreutils/rm at lowest support level does not work
|
|
|
|
|
# with the git test structure. Long paths as in
|
|
|
|
|
# 'trash directory...' cause rm to terminate prematurely without fully
|
|
|
|
|
# removing the directory at OS releases J06.21 and L17.02.
|
|
|
|
|
# Default to the older rm until those two releases are deprecated.
|
|
|
|
|
RM = /bin/rm -f
|
|
|
|
|
NEEDS_CRYPTO_WITH_SSL = YesPlease
|
|
|
|
|
HAVE_DEV_TTY = YesPlease
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
HAVE_LIBCHARSET_H = YesPlease
|
|
|
|
|
HAVE_STRINGS_H = YesPlease
|
|
|
|
|
NEEDS_LIBICONV = YesPlease
|
|
|
|
|
NEEDS_LIBINTL_BEFORE_LIBICONV = YesPlease
|
|
|
|
|
NO_SYS_SELECT_H = UnfortunatelyYes
|
|
|
|
|
NO_D_TYPE_IN_DIRENT = YesPlease
|
2019-01-04 00:03:49 +03:00
|
|
|
NO_GETTEXT = YesPlease
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
NO_HSTRERROR = YesPlease
|
|
|
|
|
NO_STRCASESTR = YesPlease
|
|
|
|
|
NO_MEMMEM = YesPlease
|
|
|
|
|
NO_STRLCPY = YesPlease
|
|
|
|
|
NO_SETENV = YesPlease
|
|
|
|
|
NO_UNSETENV = YesPlease
|
|
|
|
|
NO_MKDTEMP = YesPlease
|
|
|
|
|
# Currently libiconv-1.9.1.
|
|
|
|
|
OLD_ICONV = UnfortunatelyYes
|
2019-01-04 00:03:49 +03:00
|
|
|
NO_REGEX = NeedsStartEnd
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
NO_PTHREADS = UnfortunatelyYes
|
2019-02-10 03:20:16 +03:00
|
|
|
FREAD_READS_DIRECTORIES = UnfortunatelyYes
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
|
|
|
|
|
# Not detected (nor checked for) by './configure'.
|
|
|
|
|
# We don't have SA_RESTART on NonStop, unfortunalety.
|
|
|
|
|
COMPAT_CFLAGS += -DSA_RESTART=0
|
|
|
|
|
# Apparently needed in compat/fnmatch/fnmatch.c.
|
|
|
|
|
COMPAT_CFLAGS += -DHAVE_STRING_H=1
|
|
|
|
|
NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
|
|
|
|
|
NO_NSEC = YesPlease
|
|
|
|
|
NO_PREAD = YesPlease
|
|
|
|
|
NO_MMAP = YesPlease
|
|
|
|
|
NO_POLL = YesPlease
|
|
|
|
|
NO_INTPTR_T = UnfortunatelyYes
|
wrapper: add a helper to generate numbers from a CSPRNG
There are many situations in which having access to a cryptographically
secure pseudorandom number generator (CSPRNG) is helpful. In the
future, we'll encounter one of these when dealing with temporary files.
To make this possible, let's add a function which reads from a system
CSPRNG and returns some bytes.
We know that all systems will have such an interface. A CSPRNG is
required for a secure TLS or SSH implementation and a Git implementation
which provided neither would be of little practical use. In addition,
POSIX is set to standardize getentropy(2) in the next version, so in the
(potentially distant) future we can rely on that.
For systems which lack one of the other interfaces, we provide the
ability to use OpenSSL's CSPRNG. OpenSSL is highly portable and
functions on practically every known OS, and we know it will have access
to some source of cryptographically secure randomness. We also provide
support for the arc4random in libbsd for folks who would prefer to use
that.
Because this is a security sensitive interface, we take some
precautions. We either succeed by filling the buffer completely as we
requested, or we fail. We don't return partial data because the caller
will almost never find that to be a useful behavior.
Specify a makefile knob which users can use to specify one or more
suitable CSPRNGs, and turn the multiple string options into a set of
defines, since we cannot match on strings in the preprocessor. We allow
multiple options to make the job of handling this in autoconf easier.
The order of options is important here. On systems with arc4random,
which is most of the BSDs, we use that, since, except on MirBSD and
macOS, it uses ChaCha20, which is extremely fast, and sits entirely in
userspace, avoiding a system call. We then prefer getrandom over
getentropy, because the former has been available longer on Linux, and
then OpenSSL. Finally, if none of those are available, we use
/dev/urandom, because most Unix-like operating systems provide that API.
We prefer options that don't involve device files when possible because
those work in some restricted environments where device files may not be
available.
Set the configuration variables appropriately for Linux and the BSDs,
including macOS, as well as Windows and NonStop. We specifically only
consider versions which receive publicly available security support
here. For the same reason, we don't specify getrandom(2) on Linux,
because CentOS 7 doesn't support it in glibc (although its kernel does)
and we don't want to resort to making syscalls.
Finally, add a test helper to allow this to be tested by hand and in
tests. We don't add any tests, since invoking the CSPRNG is not likely
to produce interesting, reproducible results.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-18 00:56:16 +03:00
|
|
|
CSPRNG_METHOD = openssl
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
SANE_TOOL_PATH = /usr/coreutils/bin:/usr/local/bin
|
2019-02-09 20:26:11 +03:00
|
|
|
SHELL_PATH = /usr/coreutils/bin/bash
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
endif
|
2021-09-29 06:19:40 +03:00
|
|
|
ifeq ($(uname_S),MINGW)
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
pathsep = ;
|
2014-04-09 16:48:27 +04:00
|
|
|
HAVE_ALLOCA_H = YesPlease
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
NO_PREAD = YesPlease
|
|
|
|
|
NEEDS_CRYPTO_WITH_SSL = YesPlease
|
|
|
|
|
NO_LIBGEN_H = YesPlease
|
|
|
|
|
NO_POLL = YesPlease
|
|
|
|
|
NO_SYMLINK_HEAD = YesPlease
|
|
|
|
|
NO_UNIX_SOCKETS = YesPlease
|
|
|
|
|
NO_SETENV = YesPlease
|
|
|
|
|
NO_STRCASESTR = YesPlease
|
|
|
|
|
NO_STRLCPY = YesPlease
|
|
|
|
|
NO_MEMMEM = YesPlease
|
|
|
|
|
NEEDS_LIBICONV = YesPlease
|
|
|
|
|
NO_STRTOUMAX = YesPlease
|
|
|
|
|
NO_MKDTEMP = YesPlease
|
|
|
|
|
NO_SVN_TESTS = YesPlease
|
2022-03-25 21:02:51 +03:00
|
|
|
|
|
|
|
|
# The builtin FSMonitor requires Named Pipes and Threads on Windows.
|
|
|
|
|
# These are always available, so we do not have to conditionally
|
|
|
|
|
# support it.
|
|
|
|
|
FSMONITOR_DAEMON_BACKEND = win32
|
2022-05-27 00:46:59 +03:00
|
|
|
FSMONITOR_OS_SETTINGS = win32
|
|
|
|
|
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
RUNTIME_PREFIX = YesPlease
|
2018-04-10 18:05:46 +03:00
|
|
|
HAVE_WPGMPTR = YesWeDo
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
|
2021-03-16 00:08:23 +03:00
|
|
|
USE_WIN32_IPC = YesPlease
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
USE_WIN32_MMAP = YesPlease
|
2017-09-25 11:00:10 +03:00
|
|
|
MMAP_PREVENTS_DELETE = UnfortunatelyYes
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
USE_NED_ALLOCATOR = YesPlease
|
|
|
|
|
UNRELIABLE_FSTAT = UnfortunatelyYes
|
|
|
|
|
OBJECT_CREATION_USES_RENAMES = UnfortunatelyNeedsTo
|
|
|
|
|
NO_REGEX = YesPlease
|
|
|
|
|
ETAGS_TARGET = ETAGS
|
|
|
|
|
NO_POSIX_GOODIES = UnfortunatelyYes
|
2012-06-21 15:24:14 +04:00
|
|
|
DEFAULT_HELP_FORMAT = html
|
2021-07-22 04:27:06 +03:00
|
|
|
HAVE_PLATFORM_PROCINFO = YesPlease
|
wrapper: add a helper to generate numbers from a CSPRNG
There are many situations in which having access to a cryptographically
secure pseudorandom number generator (CSPRNG) is helpful. In the
future, we'll encounter one of these when dealing with temporary files.
To make this possible, let's add a function which reads from a system
CSPRNG and returns some bytes.
We know that all systems will have such an interface. A CSPRNG is
required for a secure TLS or SSH implementation and a Git implementation
which provided neither would be of little practical use. In addition,
POSIX is set to standardize getentropy(2) in the next version, so in the
(potentially distant) future we can rely on that.
For systems which lack one of the other interfaces, we provide the
ability to use OpenSSL's CSPRNG. OpenSSL is highly portable and
functions on practically every known OS, and we know it will have access
to some source of cryptographically secure randomness. We also provide
support for the arc4random in libbsd for folks who would prefer to use
that.
Because this is a security sensitive interface, we take some
precautions. We either succeed by filling the buffer completely as we
requested, or we fail. We don't return partial data because the caller
will almost never find that to be a useful behavior.
Specify a makefile knob which users can use to specify one or more
suitable CSPRNGs, and turn the multiple string options into a set of
defines, since we cannot match on strings in the preprocessor. We allow
multiple options to make the job of handling this in autoconf easier.
The order of options is important here. On systems with arc4random,
which is most of the BSDs, we use that, since, except on MirBSD and
macOS, it uses ChaCha20, which is extremely fast, and sits entirely in
userspace, avoiding a system call. We then prefer getrandom over
getentropy, because the former has been available longer on Linux, and
then OpenSSL. Finally, if none of those are available, we use
/dev/urandom, because most Unix-like operating systems provide that API.
We prefer options that don't involve device files when possible because
those work in some restricted environments where device files may not be
available.
Set the configuration variables appropriately for Linux and the BSDs,
including macOS, as well as Windows and NonStop. We specifically only
consider versions which receive publicly available security support
here. For the same reason, we don't specify getrandom(2) on Linux,
because CentOS 7 doesn't support it in glibc (although its kernel does)
and we don't want to resort to making syscalls.
Finally, add a test helper to allow this to be tested by hand and in
tests. We don't add any tests, since invoking the CSPRNG is not likely
to produce interesting, reproducible results.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-18 00:56:16 +03:00
|
|
|
CSPRNG_METHOD = rtlgenrandom
|
mingw: replace mingw_startup() hack
Git for Windows has special code to retrieve the command-line parameters
(and even the environment) in UTF-16 encoding, so that they can be
converted to UTF-8. This is necessary because Git for Windows wants to
use UTF-8 encoded strings throughout its code, and the main() function
does not get the parameters in that encoding.
To do that, we used the __wgetmainargs() function, which is not even a
Win32 API function, but provided by the MINGW "runtime" instead.
Obviously, this method would not work with any compiler other than GCC,
and in preparation for compiling with Visual C++, we would like to avoid
precisely that.
Lucky us, there is a much more elegant way: we can simply implement the
UTF-16 variant of `main()`: `wmain()`.
To make that work, we need to link with -municode. The command-line
parameters are passed to `wmain()` encoded in UTF-16, as desired, and
this method also works with GCC, and also with Visual C++ after
adjusting the MSVC linker flags to force it to use `wmain()`.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-20 00:05:59 +03:00
|
|
|
BASIC_LDFLAGS += -municode
|
2016-01-13 16:31:01 +03:00
|
|
|
COMPAT_CFLAGS += -DNOGDI -Icompat -Icompat/win32
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
COMPAT_CFLAGS += -DSTRIP_EXTENSION=\".exe\"
|
|
|
|
|
COMPAT_OBJS += compat/mingw.o compat/winansi.o \
|
2019-02-23 01:25:02 +03:00
|
|
|
compat/win32/trace2_win32_process_info.o \
|
2022-03-11 01:43:20 +03:00
|
|
|
compat/win32/flush.o \
|
2018-12-15 07:33:30 +03:00
|
|
|
compat/win32/path-utils.o \
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
compat/win32/pthread.o compat/win32/syslog.o \
|
|
|
|
|
compat/win32/dirent.o
|
2019-12-05 00:27:04 +03:00
|
|
|
BASIC_CFLAGS += -DWIN32
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
EXTLIBS += -lws2_32
|
2012-05-24 03:56:24 +04:00
|
|
|
GITLIBS += git.res
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
PTHREAD_LIBS =
|
2012-05-24 03:56:24 +04:00
|
|
|
RC = windres -O coff
|
2010-09-04 12:25:09 +04:00
|
|
|
NATIVE_CRLF = YesPlease
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
X = .exe
|
|
|
|
|
ifneq (,$(wildcard ../THIS_IS_MSYSGIT))
|
|
|
|
|
htmldir = doc/git/html/
|
|
|
|
|
prefix =
|
|
|
|
|
INSTALL = /bin/install
|
|
|
|
|
EXTLIBS += /mingw/lib/libz.a
|
|
|
|
|
INTERNAL_QSORT = YesPlease
|
|
|
|
|
HAVE_LIBCHARSET_H = YesPlease
|
2012-01-06 02:41:41 +04:00
|
|
|
NO_GETTEXT = YesPlease
|
2022-07-29 18:41:09 +03:00
|
|
|
NO_PYTHON = YesPlease
|
2019-06-20 00:05:56 +03:00
|
|
|
COMPAT_CFLAGS += -D__USE_MINGW_ACCESS
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
else
|
2019-03-08 18:51:19 +03:00
|
|
|
ifneq ($(shell expr "$(uname_R)" : '1\.'),2)
|
config.mak.uname: support MSys2
For a long time, Git for Windows lagged behind Git's 2.x releases because
the Git for Windows developers wanted to let that big jump coincide with
a well-needed jump away from MSys to MSys2.
To understand why this is such a big issue, it needs to be noted that
many parts of Git are not written in portable C, but instead Git relies
on a POSIX shell and Perl to be available.
To support the scripts, Git for Windows has to ship a minimal POSIX
emulation layer with Bash and Perl thrown in, and when the Git for
Windows effort started in August 2007, this developer settled on using
MSys, a stripped down version of Cygwin. Consequently, the original name
of the project was "msysGit" (which, sadly, caused a *lot* of confusion
because few Windows users know about MSys, and even less care).
To compile the C code of Git for Windows, MSys was used, too: it sports
two versions of the GNU C Compiler: one that links implicitly to the
POSIX emulation layer, and another one that targets the plain Win32 API
(with a few convenience functions thrown in). Git for Windows'
executables are built using the latter, and therefore they are really
just Win32 programs. To discern executables requiring the POSIX
emulation layer from the ones that do not, the latter are called MinGW
(Minimal GNU for Windows) when the former are called MSys executables.
This reliance on MSys incurred challenges, too, though: some of our
changes to the MSys runtime -- necessary to support Git for Windows
better -- were not accepted upstream, so we had to maintain our own
fork. Also, the MSys runtime was not developed further to support e.g.
UTF-8 or 64-bit, and apart from lacking a package management system
until much later (when mingw-get was introduced), many packages provided
by the MSys/MinGW project lag behind the respective source code
versions, in particular Bash and OpenSSL. For a while, the Git for
Windows project tried to remedy the situation by trying to build newer
versions of those packages, but the situation quickly became untenable,
especially with problems like the Heartbleed bug requiring swift action
that has nothing to do with developing Git for Windows further.
Happily, in the meantime the MSys2 project (https://msys2.github.io/)
emerged, and was chosen to be the base of the Git for Windows 2.x. Just
like MSys, MSys2 is a stripped down version of Cygwin, but it is
actively kept up-to-date with Cygwin's source code. Thereby, it already
supports Unicode internally, and it also offers the 64-bit support that
we yearned for since the beginning of the Git for Windows project.
MSys2 also ported the Pacman package management system from Arch Linux
and uses it heavily. This brings the same convenience to which Linux
users are used to from `yum` or `apt-get`, and to which MacOSX users are
used to from Homebrew or MacPorts, or BSD users from the Ports system,
to MSys2: a simple `pacman -Syu` will update all installed packages to
the newest versions currently available.
MSys2 is also *very* active, typically providing package updates
multiple times per week.
It still required a two-month effort to bring everything to a state
where Git's test suite passes, many more months until the first official
Git for Windows 2.x was released, and a couple of patches still await
their submission to the respective upstream projects. Yet without MSys2,
the modernization of Git for Windows would simply not have happened.
This commit lays the ground work to supporting MSys2-based Git builds.
Assisted-by: Waldek Maleska <weakcamel@users.github.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13 16:30:53 +03:00
|
|
|
# MSys2
|
2016-01-13 16:31:01 +03:00
|
|
|
prefix = /usr/
|
2019-05-08 14:30:59 +03:00
|
|
|
# Enable DEP
|
|
|
|
|
BASIC_LDFLAGS += -Wl,--nxcompat
|
|
|
|
|
# Enable ASLR (unless debugging)
|
|
|
|
|
ifneq (,$(findstring -O,$(filter-out -O0 -Og,$(CFLAGS))))
|
|
|
|
|
BASIC_LDFLAGS += -Wl,--dynamicbase
|
|
|
|
|
endif
|
2016-01-13 16:31:01 +03:00
|
|
|
ifeq (MINGW32,$(MSYSTEM))
|
|
|
|
|
prefix = /mingw32
|
mingw: use a more canonical method to fix the CPU reporting
In `git version --build-options`, we report also the CPU, but in Git for
Windows we actually cross-compile the 32-bit version in a 64-bit Git for
Windows, so we cannot rely on the auto-detected value.
In 3815f64b0dd9 (mingw: fix CPU reporting in `git version
--build-options`, 2019-02-07), we fixed this by a Windows-only
workaround, making use of magic pre-processor constants, which works in
GCC, but most likely not all C compilers.
As pointed out by Eric Sunshine, there is a better way, anyway: to set
the Makefile variable HOST_CPU explicitly for cross-compiled Git. So
let's do that!
This reverts commit 3815f64b0dd983bdbf9242a0547706d5d81cb3e6 partially.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-13 13:19:49 +03:00
|
|
|
HOST_CPU = i686
|
2019-05-08 14:30:58 +03:00
|
|
|
BASIC_LDFLAGS += -Wl,--pic-executable,-e,_mainCRTStartup
|
2016-01-13 16:31:01 +03:00
|
|
|
endif
|
|
|
|
|
ifeq (MINGW64,$(MSYSTEM))
|
|
|
|
|
prefix = /mingw64
|
mingw: use a more canonical method to fix the CPU reporting
In `git version --build-options`, we report also the CPU, but in Git for
Windows we actually cross-compile the 32-bit version in a 64-bit Git for
Windows, so we cannot rely on the auto-detected value.
In 3815f64b0dd9 (mingw: fix CPU reporting in `git version
--build-options`, 2019-02-07), we fixed this by a Windows-only
workaround, making use of magic pre-processor constants, which works in
GCC, but most likely not all C compilers.
As pointed out by Eric Sunshine, there is a better way, anyway: to set
the Makefile variable HOST_CPU explicitly for cross-compiled Git. So
let's do that!
This reverts commit 3815f64b0dd983bdbf9242a0547706d5d81cb3e6 partially.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-13 13:19:49 +03:00
|
|
|
HOST_CPU = x86_64
|
2019-05-08 14:30:58 +03:00
|
|
|
BASIC_LDFLAGS += -Wl,--pic-executable,-e,mainCRTStartup
|
2016-01-13 16:31:01 +03:00
|
|
|
else
|
|
|
|
|
COMPAT_CFLAGS += -D_USE_32BIT_TIME_T
|
|
|
|
|
BASIC_LDFLAGS += -Wl,--large-address-aware
|
|
|
|
|
endif
|
config.mak.uname: support MSys2
For a long time, Git for Windows lagged behind Git's 2.x releases because
the Git for Windows developers wanted to let that big jump coincide with
a well-needed jump away from MSys to MSys2.
To understand why this is such a big issue, it needs to be noted that
many parts of Git are not written in portable C, but instead Git relies
on a POSIX shell and Perl to be available.
To support the scripts, Git for Windows has to ship a minimal POSIX
emulation layer with Bash and Perl thrown in, and when the Git for
Windows effort started in August 2007, this developer settled on using
MSys, a stripped down version of Cygwin. Consequently, the original name
of the project was "msysGit" (which, sadly, caused a *lot* of confusion
because few Windows users know about MSys, and even less care).
To compile the C code of Git for Windows, MSys was used, too: it sports
two versions of the GNU C Compiler: one that links implicitly to the
POSIX emulation layer, and another one that targets the plain Win32 API
(with a few convenience functions thrown in). Git for Windows'
executables are built using the latter, and therefore they are really
just Win32 programs. To discern executables requiring the POSIX
emulation layer from the ones that do not, the latter are called MinGW
(Minimal GNU for Windows) when the former are called MSys executables.
This reliance on MSys incurred challenges, too, though: some of our
changes to the MSys runtime -- necessary to support Git for Windows
better -- were not accepted upstream, so we had to maintain our own
fork. Also, the MSys runtime was not developed further to support e.g.
UTF-8 or 64-bit, and apart from lacking a package management system
until much later (when mingw-get was introduced), many packages provided
by the MSys/MinGW project lag behind the respective source code
versions, in particular Bash and OpenSSL. For a while, the Git for
Windows project tried to remedy the situation by trying to build newer
versions of those packages, but the situation quickly became untenable,
especially with problems like the Heartbleed bug requiring swift action
that has nothing to do with developing Git for Windows further.
Happily, in the meantime the MSys2 project (https://msys2.github.io/)
emerged, and was chosen to be the base of the Git for Windows 2.x. Just
like MSys, MSys2 is a stripped down version of Cygwin, but it is
actively kept up-to-date with Cygwin's source code. Thereby, it already
supports Unicode internally, and it also offers the 64-bit support that
we yearned for since the beginning of the Git for Windows project.
MSys2 also ported the Pacman package management system from Arch Linux
and uses it heavily. This brings the same convenience to which Linux
users are used to from `yum` or `apt-get`, and to which MacOSX users are
used to from Homebrew or MacPorts, or BSD users from the Ports system,
to MSys2: a simple `pacman -Syu` will update all installed packages to
the newest versions currently available.
MSys2 is also *very* active, typically providing package updates
multiple times per week.
It still required a two-month effort to bring everything to a state
where Git's test suite passes, many more months until the first official
Git for Windows 2.x was released, and a couple of patches still await
their submission to the respective upstream projects. Yet without MSys2,
the modernization of Git for Windows would simply not have happened.
This commit lays the ground work to supporting MSys2-based Git builds.
Assisted-by: Waldek Maleska <weakcamel@users.github.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13 16:30:53 +03:00
|
|
|
CC = gcc
|
2019-06-27 12:29:02 +03:00
|
|
|
COMPAT_CFLAGS += -D__USE_MINGW_ANSI_STDIO=0 -DDETECT_MSYS_TTY \
|
|
|
|
|
-fstack-protector-strong
|
2016-04-27 18:16:37 +03:00
|
|
|
EXTLIBS += -lntdll
|
config.mak.uname: support MSys2
For a long time, Git for Windows lagged behind Git's 2.x releases because
the Git for Windows developers wanted to let that big jump coincide with
a well-needed jump away from MSys to MSys2.
To understand why this is such a big issue, it needs to be noted that
many parts of Git are not written in portable C, but instead Git relies
on a POSIX shell and Perl to be available.
To support the scripts, Git for Windows has to ship a minimal POSIX
emulation layer with Bash and Perl thrown in, and when the Git for
Windows effort started in August 2007, this developer settled on using
MSys, a stripped down version of Cygwin. Consequently, the original name
of the project was "msysGit" (which, sadly, caused a *lot* of confusion
because few Windows users know about MSys, and even less care).
To compile the C code of Git for Windows, MSys was used, too: it sports
two versions of the GNU C Compiler: one that links implicitly to the
POSIX emulation layer, and another one that targets the plain Win32 API
(with a few convenience functions thrown in). Git for Windows'
executables are built using the latter, and therefore they are really
just Win32 programs. To discern executables requiring the POSIX
emulation layer from the ones that do not, the latter are called MinGW
(Minimal GNU for Windows) when the former are called MSys executables.
This reliance on MSys incurred challenges, too, though: some of our
changes to the MSys runtime -- necessary to support Git for Windows
better -- were not accepted upstream, so we had to maintain our own
fork. Also, the MSys runtime was not developed further to support e.g.
UTF-8 or 64-bit, and apart from lacking a package management system
until much later (when mingw-get was introduced), many packages provided
by the MSys/MinGW project lag behind the respective source code
versions, in particular Bash and OpenSSL. For a while, the Git for
Windows project tried to remedy the situation by trying to build newer
versions of those packages, but the situation quickly became untenable,
especially with problems like the Heartbleed bug requiring swift action
that has nothing to do with developing Git for Windows further.
Happily, in the meantime the MSys2 project (https://msys2.github.io/)
emerged, and was chosen to be the base of the Git for Windows 2.x. Just
like MSys, MSys2 is a stripped down version of Cygwin, but it is
actively kept up-to-date with Cygwin's source code. Thereby, it already
supports Unicode internally, and it also offers the 64-bit support that
we yearned for since the beginning of the Git for Windows project.
MSys2 also ported the Pacman package management system from Arch Linux
and uses it heavily. This brings the same convenience to which Linux
users are used to from `yum` or `apt-get`, and to which MacOSX users are
used to from Homebrew or MacPorts, or BSD users from the Ports system,
to MSys2: a simple `pacman -Syu` will update all installed packages to
the newest versions currently available.
MSys2 is also *very* active, typically providing package updates
multiple times per week.
It still required a two-month effort to bring everything to a state
where Git's test suite passes, many more months until the first official
Git for Windows 2.x was released, and a couple of patches still await
their submission to the respective upstream projects. Yet without MSys2,
the modernization of Git for Windows would simply not have happened.
This commit lays the ground work to supporting MSys2-based Git builds.
Assisted-by: Waldek Maleska <weakcamel@users.github.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13 16:30:53 +03:00
|
|
|
INSTALL = /bin/install
|
|
|
|
|
INTERNAL_QSORT = YesPlease
|
|
|
|
|
HAVE_LIBCHARSET_H = YesPlease
|
2016-01-26 17:34:30 +03:00
|
|
|
USE_GETTEXT_SCHEME = fallthrough
|
2021-06-22 13:42:41 +03:00
|
|
|
USE_LIBPCRE = YesPlease
|
config.mak.uname: support MSys2
For a long time, Git for Windows lagged behind Git's 2.x releases because
the Git for Windows developers wanted to let that big jump coincide with
a well-needed jump away from MSys to MSys2.
To understand why this is such a big issue, it needs to be noted that
many parts of Git are not written in portable C, but instead Git relies
on a POSIX shell and Perl to be available.
To support the scripts, Git for Windows has to ship a minimal POSIX
emulation layer with Bash and Perl thrown in, and when the Git for
Windows effort started in August 2007, this developer settled on using
MSys, a stripped down version of Cygwin. Consequently, the original name
of the project was "msysGit" (which, sadly, caused a *lot* of confusion
because few Windows users know about MSys, and even less care).
To compile the C code of Git for Windows, MSys was used, too: it sports
two versions of the GNU C Compiler: one that links implicitly to the
POSIX emulation layer, and another one that targets the plain Win32 API
(with a few convenience functions thrown in). Git for Windows'
executables are built using the latter, and therefore they are really
just Win32 programs. To discern executables requiring the POSIX
emulation layer from the ones that do not, the latter are called MinGW
(Minimal GNU for Windows) when the former are called MSys executables.
This reliance on MSys incurred challenges, too, though: some of our
changes to the MSys runtime -- necessary to support Git for Windows
better -- were not accepted upstream, so we had to maintain our own
fork. Also, the MSys runtime was not developed further to support e.g.
UTF-8 or 64-bit, and apart from lacking a package management system
until much later (when mingw-get was introduced), many packages provided
by the MSys/MinGW project lag behind the respective source code
versions, in particular Bash and OpenSSL. For a while, the Git for
Windows project tried to remedy the situation by trying to build newer
versions of those packages, but the situation quickly became untenable,
especially with problems like the Heartbleed bug requiring swift action
that has nothing to do with developing Git for Windows further.
Happily, in the meantime the MSys2 project (https://msys2.github.io/)
emerged, and was chosen to be the base of the Git for Windows 2.x. Just
like MSys, MSys2 is a stripped down version of Cygwin, but it is
actively kept up-to-date with Cygwin's source code. Thereby, it already
supports Unicode internally, and it also offers the 64-bit support that
we yearned for since the beginning of the Git for Windows project.
MSys2 also ported the Pacman package management system from Arch Linux
and uses it heavily. This brings the same convenience to which Linux
users are used to from `yum` or `apt-get`, and to which MacOSX users are
used to from Homebrew or MacPorts, or BSD users from the Ports system,
to MSys2: a simple `pacman -Syu` will update all installed packages to
the newest versions currently available.
MSys2 is also *very* active, typically providing package updates
multiple times per week.
It still required a two-month effort to bring everything to a state
where Git's test suite passes, many more months until the first official
Git for Windows 2.x was released, and a couple of patches still await
their submission to the respective upstream projects. Yet without MSys2,
the modernization of Git for Windows would simply not have happened.
This commit lays the ground work to supporting MSys2-based Git builds.
Assisted-by: Waldek Maleska <weakcamel@users.github.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13 16:30:53 +03:00
|
|
|
USE_NED_ALLOCATOR = YesPlease
|
mingw: move Git for Windows' system config where users expect it
Git for Windows' prefix is `/mingw64/` (or `/mingw32/` for 32-bit
versions), therefore the system config is located at the clunky location
`C:\Program Files\Git\mingw64\etc\gitconfig`.
This moves the system config into a more logical location: the `mingw64`
part of `C:\Program Files\Git\mingw64\etc\gitconfig` never made sense,
as it is a mere implementation detail. Let's skip the `mingw64` part and
move this to `C:\Program Files\Git\etc\gitconfig`.
Side note: in the rare (and not recommended) case a user chooses to
install 32-bit Git for Windows on a 64-bit system, the path will of
course be `C:\Program Files (x86)\Git\etc\gitconfig`.
Background: During the Git for Windows v1.x days, the system config was
located at `C:\Program Files (x86)\Git\etc\gitconfig`. With Git for
Windows v2.x, it moved to `C:\Program Files\Git\mingw64\gitconfig` (or
`C:\Program Files (x86)\Git\mingw32\gitconfig`). Rather than fixing it
back then, we tried to introduce a "Windows-wide" config, but that never
caught on.
Likewise, we move the system `gitattributes` into the same directory.
Obviously, we are cautious to do this only for the known install
locations `/mingw64` and `/mingw32`; If anybody wants to override that
while building their version of Git (e.g. via `make prefix=$HOME`), we
leave the default location of the system config and gitattributes alone.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-06-22 13:46:46 +03:00
|
|
|
ifeq (/mingw64,$(subst 32,64,$(prefix)))
|
|
|
|
|
# Move system config into top-level /etc/
|
|
|
|
|
ETC_GITCONFIG = ../etc/gitconfig
|
|
|
|
|
ETC_GITATTRIBUTES = ../etc/gitattributes
|
|
|
|
|
endif
|
config.mak.uname: support MSys2
For a long time, Git for Windows lagged behind Git's 2.x releases because
the Git for Windows developers wanted to let that big jump coincide with
a well-needed jump away from MSys to MSys2.
To understand why this is such a big issue, it needs to be noted that
many parts of Git are not written in portable C, but instead Git relies
on a POSIX shell and Perl to be available.
To support the scripts, Git for Windows has to ship a minimal POSIX
emulation layer with Bash and Perl thrown in, and when the Git for
Windows effort started in August 2007, this developer settled on using
MSys, a stripped down version of Cygwin. Consequently, the original name
of the project was "msysGit" (which, sadly, caused a *lot* of confusion
because few Windows users know about MSys, and even less care).
To compile the C code of Git for Windows, MSys was used, too: it sports
two versions of the GNU C Compiler: one that links implicitly to the
POSIX emulation layer, and another one that targets the plain Win32 API
(with a few convenience functions thrown in). Git for Windows'
executables are built using the latter, and therefore they are really
just Win32 programs. To discern executables requiring the POSIX
emulation layer from the ones that do not, the latter are called MinGW
(Minimal GNU for Windows) when the former are called MSys executables.
This reliance on MSys incurred challenges, too, though: some of our
changes to the MSys runtime -- necessary to support Git for Windows
better -- were not accepted upstream, so we had to maintain our own
fork. Also, the MSys runtime was not developed further to support e.g.
UTF-8 or 64-bit, and apart from lacking a package management system
until much later (when mingw-get was introduced), many packages provided
by the MSys/MinGW project lag behind the respective source code
versions, in particular Bash and OpenSSL. For a while, the Git for
Windows project tried to remedy the situation by trying to build newer
versions of those packages, but the situation quickly became untenable,
especially with problems like the Heartbleed bug requiring swift action
that has nothing to do with developing Git for Windows further.
Happily, in the meantime the MSys2 project (https://msys2.github.io/)
emerged, and was chosen to be the base of the Git for Windows 2.x. Just
like MSys, MSys2 is a stripped down version of Cygwin, but it is
actively kept up-to-date with Cygwin's source code. Thereby, it already
supports Unicode internally, and it also offers the 64-bit support that
we yearned for since the beginning of the Git for Windows project.
MSys2 also ported the Pacman package management system from Arch Linux
and uses it heavily. This brings the same convenience to which Linux
users are used to from `yum` or `apt-get`, and to which MacOSX users are
used to from Homebrew or MacPorts, or BSD users from the Ports system,
to MSys2: a simple `pacman -Syu` will update all installed packages to
the newest versions currently available.
MSys2 is also *very* active, typically providing package updates
multiple times per week.
It still required a two-month effort to bring everything to a state
where Git's test suite passes, many more months until the first official
Git for Windows 2.x was released, and a couple of patches still await
their submission to the respective upstream projects. Yet without MSys2,
the modernization of Git for Windows would simply not have happened.
This commit lays the ground work to supporting MSys2-based Git builds.
Assisted-by: Waldek Maleska <weakcamel@users.github.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13 16:30:53 +03:00
|
|
|
else
|
|
|
|
|
COMPAT_CFLAGS += -D__USE_MINGW_ANSI_STDIO
|
|
|
|
|
NO_CURL = YesPlease
|
2022-07-29 18:41:09 +03:00
|
|
|
NO_PYTHON = YesPlease
|
config.mak.uname: support MSys2
For a long time, Git for Windows lagged behind Git's 2.x releases because
the Git for Windows developers wanted to let that big jump coincide with
a well-needed jump away from MSys to MSys2.
To understand why this is such a big issue, it needs to be noted that
many parts of Git are not written in portable C, but instead Git relies
on a POSIX shell and Perl to be available.
To support the scripts, Git for Windows has to ship a minimal POSIX
emulation layer with Bash and Perl thrown in, and when the Git for
Windows effort started in August 2007, this developer settled on using
MSys, a stripped down version of Cygwin. Consequently, the original name
of the project was "msysGit" (which, sadly, caused a *lot* of confusion
because few Windows users know about MSys, and even less care).
To compile the C code of Git for Windows, MSys was used, too: it sports
two versions of the GNU C Compiler: one that links implicitly to the
POSIX emulation layer, and another one that targets the plain Win32 API
(with a few convenience functions thrown in). Git for Windows'
executables are built using the latter, and therefore they are really
just Win32 programs. To discern executables requiring the POSIX
emulation layer from the ones that do not, the latter are called MinGW
(Minimal GNU for Windows) when the former are called MSys executables.
This reliance on MSys incurred challenges, too, though: some of our
changes to the MSys runtime -- necessary to support Git for Windows
better -- were not accepted upstream, so we had to maintain our own
fork. Also, the MSys runtime was not developed further to support e.g.
UTF-8 or 64-bit, and apart from lacking a package management system
until much later (when mingw-get was introduced), many packages provided
by the MSys/MinGW project lag behind the respective source code
versions, in particular Bash and OpenSSL. For a while, the Git for
Windows project tried to remedy the situation by trying to build newer
versions of those packages, but the situation quickly became untenable,
especially with problems like the Heartbleed bug requiring swift action
that has nothing to do with developing Git for Windows further.
Happily, in the meantime the MSys2 project (https://msys2.github.io/)
emerged, and was chosen to be the base of the Git for Windows 2.x. Just
like MSys, MSys2 is a stripped down version of Cygwin, but it is
actively kept up-to-date with Cygwin's source code. Thereby, it already
supports Unicode internally, and it also offers the 64-bit support that
we yearned for since the beginning of the Git for Windows project.
MSys2 also ported the Pacman package management system from Arch Linux
and uses it heavily. This brings the same convenience to which Linux
users are used to from `yum` or `apt-get`, and to which MacOSX users are
used to from Homebrew or MacPorts, or BSD users from the Ports system,
to MSys2: a simple `pacman -Syu` will update all installed packages to
the newest versions currently available.
MSys2 is also *very* active, typically providing package updates
multiple times per week.
It still required a two-month effort to bring everything to a state
where Git's test suite passes, many more months until the first official
Git for Windows 2.x was released, and a couple of patches still await
their submission to the respective upstream projects. Yet without MSys2,
the modernization of Git for Windows would simply not have happened.
This commit lays the ground work to supporting MSys2-based Git builds.
Assisted-by: Waldek Maleska <weakcamel@users.github.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13 16:30:53 +03:00
|
|
|
endif
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(uname_S),QNX)
|
|
|
|
|
COMPAT_CFLAGS += -DSA_RESTART=0
|
2013-02-12 02:03:45 +04:00
|
|
|
EXPAT_NEEDS_XMLPARSE_H = YesPlease
|
Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-04 01:05:41 +04:00
|
|
|
HAVE_STRINGS_H = YesPlease
|
|
|
|
|
NEEDS_SOCKET = YesPlease
|
|
|
|
|
NO_GETPAGESIZE = YesPlease
|
|
|
|
|
NO_ICONV = YesPlease
|
|
|
|
|
NO_MEMMEM = YesPlease
|
|
|
|
|
NO_MKDTEMP = YesPlease
|
|
|
|
|
NO_NSEC = YesPlease
|
|
|
|
|
NO_PTHREADS = YesPlease
|
|
|
|
|
NO_STRCASESTR = YesPlease
|
|
|
|
|
NO_STRLCPY = YesPlease
|
|
|
|
|
endif
|
2019-07-29 23:08:12 +03:00
|
|
|
|
|
|
|
|
vcxproj:
|
|
|
|
|
# Require clean work tree
|
|
|
|
|
git update-index -q --refresh && \
|
|
|
|
|
git diff-files --quiet && \
|
|
|
|
|
git diff-index --cached --quiet HEAD --
|
|
|
|
|
|
|
|
|
|
# Make .vcxproj files and add them
|
|
|
|
|
perl contrib/buildsystems/generate -g Vcxproj
|
|
|
|
|
git add -f git.sln {*,*/lib,t/helper/*}/*.vcxproj
|
|
|
|
|
|
2019-10-04 18:09:31 +03:00
|
|
|
# Generate the LinkOrCopyBuiltins.targets and LinkOrCopyRemoteHttp.targets file
|
2019-07-29 23:08:13 +03:00
|
|
|
(echo '<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">' && \
|
|
|
|
|
echo ' <Target Name="CopyBuiltins_AfterBuild" AfterTargets="AfterBuild">' && \
|
|
|
|
|
for name in $(BUILT_INS);\
|
|
|
|
|
do \
|
|
|
|
|
echo ' <Copy SourceFiles="$$(OutDir)\git.exe" DestinationFiles="$$(OutDir)\'"$$name"'" SkipUnchangedFiles="true" UseHardlinksIfPossible="true" />'; \
|
|
|
|
|
done && \
|
2019-10-04 18:09:31 +03:00
|
|
|
echo ' </Target>' && \
|
|
|
|
|
echo '</Project>') >git/LinkOrCopyBuiltins.targets
|
|
|
|
|
(echo '<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">' && \
|
|
|
|
|
echo ' <Target Name="CopyBuiltins_AfterBuild" AfterTargets="AfterBuild">' && \
|
2019-07-29 23:08:13 +03:00
|
|
|
for name in $(REMOTE_CURL_ALIASES); \
|
|
|
|
|
do \
|
|
|
|
|
echo ' <Copy SourceFiles="$$(OutDir)\'"$(REMOTE_CURL_PRIMARY)"'" DestinationFiles="$$(OutDir)\'"$$name"'" SkipUnchangedFiles="true" UseHardlinksIfPossible="true" />'; \
|
|
|
|
|
done && \
|
|
|
|
|
echo ' </Target>' && \
|
2019-10-04 18:09:31 +03:00
|
|
|
echo '</Project>') >git-remote-http/LinkOrCopyRemoteHttp.targets
|
|
|
|
|
git add -f git/LinkOrCopyBuiltins.targets git-remote-http/LinkOrCopyRemoteHttp.targets
|
2019-07-29 23:08:13 +03:00
|
|
|
|
Makefile: stop hardcoding {command,config}-list.h
Change various places that hardcode the names of these two files to
refer to either $(GENERATED_H), or to a new generated-hdrs
target. That target is consistent with the *-objs targets I recently
added in 029bac01a8 (Makefile: add {program,xdiff,test,git,fuzz}-objs
& objects targets, 2021-02-23).
A subsequent commit will add a new generated hook-list.h. By doing
this refactoring we'll only need to add the new file to the
GENERATED_H variable, not EXCEPT_HDRS, the vcbuild/README etc.
Hardcoding command-list.h there seems to have been a case of
copy/paste programming in 976aaedca0 (msvc: add a Makefile target to
pre-generate the Visual Studio solution, 2019-07-29). The
config-list.h was added later in 709df95b78 (help: move
list_config_help to builtin/help, 2020-04-16).
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-23 13:29:57 +03:00
|
|
|
# Add generated headers
|
|
|
|
|
$(MAKE) MSVC=1 SKIP_VCPKG=1 prefix=/mingw64 $(GENERATED_H)
|
|
|
|
|
git add -f $(GENERATED_H)
|
2019-07-29 23:08:12 +03:00
|
|
|
|
|
|
|
|
# Add scripts
|
|
|
|
|
rm -f perl/perl.mak
|
2019-10-04 18:09:32 +03:00
|
|
|
$(MAKE) MSVC=1 SKIP_VCPKG=1 prefix=/mingw64 $(SCRIPT_LIB) $(SCRIPTS)
|
2019-07-29 23:08:12 +03:00
|
|
|
# Strip out the sane tool path, needed only for building
|
|
|
|
|
sed -i '/^git_broken_path_fix ".*/d' git-sh-setup
|
2019-10-04 18:09:32 +03:00
|
|
|
git add -f $(SCRIPT_LIB) $(SCRIPTS)
|
2019-07-29 23:08:12 +03:00
|
|
|
|
|
|
|
|
# Add Perl module
|
|
|
|
|
$(MAKE) $(LIB_PERL_GEN)
|
|
|
|
|
git add -f perl/build
|
|
|
|
|
|
|
|
|
|
# Add bin-wrappers, for testing
|
|
|
|
|
rm -rf bin-wrappers/
|
|
|
|
|
$(MAKE) MSVC=1 SKIP_VCPKG=1 prefix=/mingw64 $(test_bindir_programs)
|
|
|
|
|
# Ensure that the GIT_EXEC_PATH is a Unix-y one, and that the absolute
|
|
|
|
|
# path of the repository is not hard-coded (GIT_EXEC_PATH will be set
|
|
|
|
|
# by test-lib.sh according to the current setup)
|
|
|
|
|
sed -i -e 's/^\(GIT_EXEC_PATH\)=.*/test -n "$${\1##*:*}" ||\
|
|
|
|
|
\1="$$(cygpath -u "$$\1")"/' \
|
|
|
|
|
-e "s|'$$(pwd)|\"\$$GIT_EXEC_PATH\"'|g" bin-wrappers/*
|
|
|
|
|
# Ensure that test-* helpers find the .dll files copied to top-level
|
|
|
|
|
sed -i 's|^PATH=.*|&:"$$GIT_EXEC_PATH"|' bin-wrappers/test-*
|
|
|
|
|
# We do not want to force hard-linking builtins
|
|
|
|
|
sed -i 's|\(git\)-\([-a-z]*\)\.exe"|\1.exe" \2|g' \
|
|
|
|
|
bin-wrappers/git-{receive-pack,upload-archive}
|
|
|
|
|
git add -f $(test_bindir_programs)
|
|
|
|
|
# remote-ext is a builtin, but invoked as if it were external
|
|
|
|
|
sed 's|receive-pack|remote-ext|g' \
|
|
|
|
|
<bin-wrappers/git-receive-pack >bin-wrappers/git-remote-ext
|
|
|
|
|
git add -f bin-wrappers/git-remote-ext
|
|
|
|
|
|
|
|
|
|
# Add templates
|
|
|
|
|
$(MAKE) -C templates
|
|
|
|
|
git add -f templates/boilerplates.made templates/blt/
|
|
|
|
|
|
2019-10-04 18:09:32 +03:00
|
|
|
# Add the translated messages
|
|
|
|
|
make MSVC=1 SKIP_VCPKG=1 prefix=/mingw64 $(MOFILES)
|
|
|
|
|
git add -f $(MOFILES)
|
|
|
|
|
|
2019-07-29 23:08:12 +03:00
|
|
|
# Add build options
|
|
|
|
|
$(MAKE) MSVC=1 SKIP_VCPKG=1 prefix=/mingw64 GIT-BUILD-OPTIONS
|
|
|
|
|
git add -f GIT-BUILD-OPTIONS
|
|
|
|
|
|
|
|
|
|
# Commit the whole shebang
|
|
|
|
|
git commit -m "Generate Visual Studio solution" \
|
|
|
|
|
-m "Auto-generated by \`$(MAKE)$(MAKEFLAGS) $@\`"
|
