Граф коммитов

201 Коммитов

Автор SHA1 Сообщение Дата
Junio C Hamano 6511cb33c9 Merge branch 'dd/sequencer-utf8'
Handling of commit objects that use non UTF-8 encoding during
"rebase -i" has been improved.

* dd/sequencer-utf8:
  sequencer: reencode commit message for am/rebase --show-current-patch
  sequencer: reencode old merge-commit message
  sequencer: reencode squashing commit's message
  sequencer: reencode revert/cherry-pick's todo list
  sequencer: reencode to utf-8 before arrange rebase's todo list
  t3900: demonstrate git-rebase problem with multi encoding
  configure.ac: define ICONV_OMITS_BOM if necessary
  t0028: eliminate non-standard usage of printf
2019-12-01 09:04:36 -08:00
Doan Tran Cong Danh 1ba6e7aecd configure.ac: define ICONV_OMITS_BOM if necessary
From commit 79444c9294, ("utf8: handle systems that don't write BOM for
UTF-16", 2019-02-12), we're supporting those systems with iconv that
omits BOM with:

    make ICONV_OMITS_BOM=Yes

However, configure script wasn't taught to detect those systems.

Teach configure to do so.

Signed-off-by: Doan Tran Cong Danh <congdanhqx@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-11 09:43:47 +09:00
Elijah Newren 15beaaa3d1 Fix spelling errors in code comments
Reported-by: Jens Schleusener <Jens.Schleusener@fossies.org>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-10 16:00:54 +09:00
Michael Osipov 9a1699c88e configure: Detect linking style for HP aCC on HP-UX
HP aCC does not accept any of the previously tested CC_LD_DYNPATH
formats, but only its own[1] "-Wl,+b" format. Add it to configure.ac.

1. http://nixdoc.net/man-pages/hp-ux/man1/ld_pa.1.html

Signed-off-by: Michael Osipov <michael.osipov@siemens.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-07 10:06:11 -07:00
Vadim Kochan b71e56a683 autoconf: #include <libintl.h> when checking for gettext()
Some libc implementations like uclibc or musl provides
gettext stubs via libintl library but this case is not checked
by AC_CHECK_LIB(c, gettext ...) because gcc has gettext as builtin
which passess the check.

So check it with included libintl.h where gettext may unfold into
libintl_gettext which will cause check to fail if libintl_gettext are
needed to be linked with -lintl.

Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-19 13:57:23 +09:00
Junio C Hamano 1c6e646235 Merge branch 'dd/poll-dot-h'
A build update.

* dd/poll-dot-h:
  git-compat-util: prefer poll.h to sys/poll.h
2018-11-19 16:24:41 +09:00
Đoàn Trần Công Danh 2648ccc231 git-compat-util: prefer poll.h to sys/poll.h
POSIX specifies that <poll.h> is the correct header for poll(2)
whereas <sys/poll.h> is only needed for some old libc.

Let's follow the POSIX way by default.

This effectively eliminates musl's warning:

    warning redirecting incorrect #include <sys/poll.h> to <poll.h>

Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14 16:32:24 +09:00
James Knight 23c4bbe28e build: link with curl-defined linker flags
Adjusting the build process to rely more on curl-config to populate
linker flags instead of manually populating flags based off detected
features.

Originally, a configure-invoked build would check for SSL-support in the
target curl library. If enabled, NEEDS_SSL_WITH_CURL would be set and
used in the Makefile to append additional libraries to link against. As
for systems building solely with make, the defines NEEDS_IDN_WITH_CURL
and NEEDS_SSL_WITH_CURL could be set to indirectly enable respective
linker flags. Since both configure.ac and Makefile already rely on
curl-config utility to provide curl-related build information, adjusting
the respective assets to populate required linker flags using the
utility (unless explicitly configured).

Signed-off-by: James Knight <james.d.knight@live.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-05 10:19:25 +09:00
Junio C Hamano 8b22d13243 Merge branch 'es/fread-reads-dir-autoconf-fix'
Small fix to the autoconf build procedure.

* es/fread-reads-dir-autoconf-fix:
  configure.ac: fix botched FREAD_READS_DIRECTORIES check
2018-04-25 13:29:01 +09:00
Eric Sunshine 249482daf0 configure.ac: fix botched FREAD_READS_DIRECTORIES check
3adf9fdecf (configure.ac: loosen FREAD_READS_DIRECTORIES test program,
2017-06-14) broke the test program for the FREAD_READS_DIRECTORIES check
by making it syntactically invalid (a dangling ")") and by botching the
type returned from 'main' (a FILE* rather than int). As a consequence,
the test program won't even compile, thus the check fails
unconditionally. Fix these problems.

Reported-by: Jonathan Primrose <jprimros@gmail.com>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-09 18:50:35 +09:00
Ævar Arnfjörð Bjarmason e6c531b808 Makefile: make USE_LIBPCRE=YesPlease mean v2, not v1
Change the USE_LIBPCRE flag from being an alias for USE_LIBPCRE1 to
being an alias for USE_LIBPCRE2.

When support for v2 was added in my 94da9193a6 ("grep: add support for
PCRE v2", 2017-06-01) the existing USE_LIBPCRE flag was left as
meaning v1, with a note that this would likely change in a future
release. That optional support for v2 first made it into Git version
2.14.0.

The PCRE v2 support has been shown to be stable, and the upstream PCRE
project is highly encouraging downstream users to move to v2, so it
makes sense to give packagers of Git who haven't heard the news about
PCRE v2 a further nudge to move to v2.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-14 15:27:50 -07:00
Ævar Arnfjörð Bjarmason a363f981ec configure: detect redundant --with-libpcre & --with-libpcre1
The --with-libpcre option is a synonym for the --with-libpcre1 flag,
but the configure script allowed for redundantly specifying both.

Nothing broke as a result of this, but it's confusing, so let's
disallow it.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-14 15:27:47 -07:00
Ævar Arnfjörð Bjarmason a91b113320 configure: fix a regression in PCRE v1 detection
Change the check for PCRE v1 to disable the --with-libpcre1 option if
the pcre_version() function can't be found in the pcre library. I
unintentionally changed this in my 94da9193a6 ("grep: add support for
PCRE v2", 2017-06-01) while renaming moving some variables.

The intent of this check ever since it was added in
a119f91e57 ("configure: Check for libpcre", 2011-05-09) is to
second-guess the user and turn off an explicitly provided
--with-libpcre if the library can't be found.

I don't think that behavior makes any sense, we shouldn't be
second-guessing the user with an auto-detection, but changing that
needs a bigger refactoring of this script, and only has marginal
benefits. So let's fix it to work as it was intended to work again.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-14 15:27:36 -07:00
Ævar Arnfjörð Bjarmason edb6a17c36 Makefile: NO_OPENSSL=1 should no longer imply BLK_SHA1=1
Use the collision detecting SHA-1 implementation by default even when
NO_OPENSSL is set.

Setting NO_OPENSSL=UnfortunatelyYes has implied BLK_SHA1=1 ever since
the former was introduced in dd53c7ab29 (Support for NO_OPENSSL,
2005-07-29).  That implication should have been removed when the
default SHA-1 implementation changed from OpenSSL to DC_SHA1 in
e6b07da278 (Makefile: make DC_SHA1 the default, 2017-03-17).  Finish
what that commit started by removing the BLK_SHA1 fallback setting so
the default DC_SHA1 implementation will be used.

Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-28 11:55:56 -08:00
Junio C Hamano df7fd961a9 Merge branch 'nd/fopen-errors'
Hotfix for a topic that is already in 'master'.

* nd/fopen-errors:
  configure.ac: loosen FREAD_READS_DIRECTORIES test program
2017-06-22 14:15:20 -07:00
Jeff King 3adf9fdecf configure.ac: loosen FREAD_READS_DIRECTORIES test program
We added an FREAD_READS_DIRECTORIES Makefile knob long ago
in cba22528f (Add compat/fopen.c which returns NULL on
attempt to open directory, 2008-02-08) to handle systems
where reading from a directory returned garbage. This works
by catching the problem at the fopen() stage and returning
NULL.

More recently, we found that there is a class of systems
(including Linux) where fopen() succeeds but fread() fails.
Since the solution is the same (having fopen return NULL),
they use the same Makefile knob as of e2d90fd1c
(config.mak.uname: set FREAD_READS_DIRECTORIES for Linux and
FreeBSD, 2017-05-03).

This works fine except for one thing: the autoconf test in
configure.ac to set FREAD_READS_DIRECTORIES actually checks
whether fread succeeds. Which means that on Linux systems,
the knob isn't set (and we even override the config.mak.uname
default). t1308 catches the failure.

We can fix this by tweaking the autoconf test to cover both
cases. In theory we might care about the distinction between
the traditional "fread reads directories" case and the new
"fopen opens directories". But since our solution catches
the problem at the fopen stage either way, we don't actually
need to know the difference. The "fopen" case is a superset.

This does mean the FREAD_READS_DIRECTORIES name is slightly
misleading. Probably FOPEN_OPENS_DIRECTORIES would be more
accurate. But it would be disruptive to simply change the
name (people's existing build configs would fail), and it's
not worth the complexity of handling both. Let's just add a
comment in the knob description.

Reported-by: Øyvind A. Holm <sunny@sunbase.org>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-15 14:14:33 -07:00
Ævar Arnfjörð Bjarmason 94da9193a6 grep: add support for PCRE v2
Add support for v2 of the PCRE API. This is a new major version of
PCRE that came out in early 2015[1].

The regular expression syntax is the same, but while the API is
similar, pretty much every function is either renamed or takes
different arguments. Thus using it via entirely new functions makes
sense, as opposed to trying to e.g. have one compile_pcre_pattern()
that would call either PCRE v1 or v2 functions.

Git can now be compiled with either USE_LIBPCRE1=YesPlease or
USE_LIBPCRE2=YesPlease, with USE_LIBPCRE=YesPlease currently being a
synonym for the former. Providing both is a compile-time error.

With earlier patches to enable JIT for PCRE v1 the performance of the
release versions of both libraries is almost exactly the same, with
PCRE v2 being around 1% slower.

However after I reported this to the pcre-dev mailing list[2] I got a
lot of help with the API use from Zoltán Herczeg, he subsequently
optimized some of the JIT functionality in v2 of the library.

Running the p7820-grep-engines.sh performance test against the latest
Subversion trunk of both, with both them and git compiled as -O3, and
the test run against linux.git, gives the following results. Just the
/perl/ tests shown:

    $ GIT_PERF_REPEAT_COUNT=30 GIT_PERF_LARGE_REPO=~/g/linux GIT_PERF_MAKE_COMMAND='grep -q LIBPCRE2 Makefile && make -j8 USE_LIBPCRE2=YesPlease CC=~/perl5/installed/bin/gcc NO_R_TO_GCC_LINKER=YesPlease CFLAGS=-O3 LIBPCREDIR=/home/avar/g/pcre2/inst LDFLAGS=-Wl,-rpath,/home/avar/g/pcre2/inst/lib || make -j8 USE_LIBPCRE=YesPlease CC=~/perl5/installed/bin/gcc NO_R_TO_GCC_LINKER=YesPlease CFLAGS=-O3 LIBPCREDIR=/home/avar/g/pcre/inst LDFLAGS=-Wl,-rpath,/home/avar/g/pcre/inst/lib' ./run HEAD~5 HEAD~ HEAD p7820-grep-engines.sh
    [...]
    Test                                            HEAD~5            HEAD~                    HEAD
    -----------------------------------------------------------------------------------------------------------------
    7820.3: perl grep 'how.to'                      0.31(1.10+0.48)   0.21(0.35+0.56) -32.3%   0.21(0.34+0.55) -32.3%
    7820.7: perl grep '^how to'                     0.56(2.70+0.40)   0.24(0.64+0.52) -57.1%   0.20(0.28+0.60) -64.3%
    7820.11: perl grep '[how] to'                   0.56(2.66+0.38)   0.29(0.95+0.45) -48.2%   0.23(0.45+0.54) -58.9%
    7820.15: perl grep '(e.t[^ ]*|v.ry) rare'       1.02(5.77+0.42)   0.31(1.02+0.54) -69.6%   0.23(0.50+0.54) -77.5%
    7820.19: perl grep 'm(ú|u)lt.b(æ|y)te'          0.38(1.57+0.42)   0.27(0.85+0.46) -28.9%   0.21(0.33+0.57) -44.7%

See commit ("perf: add a comparison test of grep regex engines",
2017-04-19) for details on the machine the above test run was executed
on.

Here HEAD~2 is git with PCRE v1 without JIT, HEAD~ is PCRE v1 with
JIT, and HEAD is PCRE v2 (also with JIT). See previous commits of mine
mentioning p7820-grep-engines.sh for more details on the test setup.

For ease of readability, a different run just of HEAD~ (PCRE v1 with
JIT v.s. PCRE v2), again with just the /perl/ tests shown:

    [...]
    Test                                            HEAD~             HEAD
    ----------------------------------------------------------------------------------------
    7820.3: perl grep 'how.to'                      0.21(0.42+0.52)   0.21(0.31+0.58) +0.0%
    7820.7: perl grep '^how to'                     0.25(0.65+0.50)   0.20(0.31+0.57) -20.0%
    7820.11: perl grep '[how] to'                   0.30(0.90+0.50)   0.23(0.46+0.53) -23.3%
    7820.15: perl grep '(e.t[^ ]*|v.ry) rare'       0.30(1.19+0.38)   0.23(0.51+0.51) -23.3%
    7820.19: perl grep 'm(ú|u)lt.b(æ|y)te'          0.27(0.84+0.48)   0.21(0.34+0.57) -22.2%

I.e. the two are either neck-to-neck, but PCRE v2 usually pulls ahead,
when it does it's around 20% faster.

A brief note on thread safety: As noted in pcre2api(3) & pcre2jit(3)
the compiled pattern can be shared between threads, but not some of
the JIT context, however the grep threading support does all pattern &
JIT compilation in separate threads, so this code doesn't need to
concern itself with thread safety.

See commit 63e7e9d8b6 ("git-grep: Learn PCRE", 2011-05-09) for the
initial addition of PCRE v1. This change follows some of the same
patterns it did (and which were discussed on list at the time),
e.g. mocking up types with typedef instead of ifdef-ing them out when
USE_LIBPCRE2 isn't defined. This adds some trivial memory use to the
program, but makes the code look nicer.

1. https://lists.exim.org/lurker/message/20150105.162835.0666407a.en.html
2. https://lists.exim.org/lurker/thread/20170419.172322.833ee099.en.html

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-02 08:29:05 +09:00
Ævar Arnfjörð Bjarmason 072473e659 Makefile & configure: reword inaccurate comment about PCRE
Reword an outdated & inaccurate comment which suggests that only
git-grep can use PCRE.

This comment was added back when PCRE support was initially added in
commit 63e7e9d8b6 ("git-grep: Learn PCRE", 2011-05-09), and was true
at the time.

It hasn't been telling the full truth since git-log learned to use
PCRE with --grep in commit 727b6fc3ed ("log --grep: accept
--basic-regexp and --perl-regexp", 2012-10-03), and more importantly
is likely to get more inaccurate over time as more use is made of PCRE
in other areas.

Reword it to be more future-proof, and to more clearly explain that
this enables user-initiated runtime behavior.

Copy/pasting this so much in configure.ac is lame, these Makefile-like
flags aren't even used by autoconf, just the corresponding
--with[out]-* options. But copy/pasting the comments that make sense
for the Makefile to configure.ac where they make less sense is the
pattern everything else follows in that file. I'm not going to war
against that as part of this change, just following the existing
pattern.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-21 08:25:37 +09:00
Ramsay Jones b2d593a779 wrapper.c: remove unused gitmkstemps() function
The last call to the mkstemps() function was removed in commit 659488326
("wrapper.c: delete dead function git_mkstemps()", 22-04-2016). In order
to support platforms without mkstemps(), this functionality was provided,
along with a Makefile build variable (NO_MKSTEMPS), by the gitmkstemps()
function. Remove the dead code, along with the defunct build machinery.

Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-28 11:54:21 -08:00
Junio C Hamano 9424bf2707 Merge branch 'js/regexec-buf'
* js/regexec-buf:
  configure.ac: improve description of NO_REGEX test
2016-10-17 13:25:21 -07:00
Jakub Narębski 842a516cb0 configure.ac: improve description of NO_REGEX test
The commit 2f8952250a ("regex: add regexec_buf() that can work on a
non NUL-terminated string", 2016-09-21) changed description of
NO_REGEX build config variable to be more neutral, and actually say
that it is about support for REG_STARTEND.  Change description in
configure.ac to match.

Change also the test message and variable name to match.  The test
just checks that REG_STARTEND is #defined.

Issue-found-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Jakub Narębski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-10 16:15:15 -07:00
Junio C Hamano 667c6d591e Merge branch 'dp/autoconf-curl-ssl'
The ./configure script generated from configure.ac was taught how
to detect support of SSL by libcurl better.

* dp/autoconf-curl-ssl:
  ./configure.ac: detect SSL in libcurl using curl-config
2016-10-10 14:03:48 -07:00
Junio C Hamano 7b01ab562a Merge branch 'ew/autoconf-pthread'
Existing autoconf generated test for the need to link with pthread
library did not check all the functions from pthread libraries;
recent FreeBSD has some functions in libc but not others, and we
mistakenly thought linking with libc is enough when it is not.

* ew/autoconf-pthread:
  configure.ac: stronger test for pthread linkage
2016-07-25 14:13:46 -07:00
Eric Wong a9b02de8b7 configure.ac: stronger test for pthread linkage
We need to test linkage of pthread_create and pthread_join,
as pthread_mutex_* and pthread_key_* functions do not need
extra linkage under FreeBSD 10.3, leading to a false-positive
of the empty case.

Signed-off-by: Eric Wong <e@80x24.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-18 11:22:35 -07:00
Дилян Палаузов 924b7eb1c9 ./configure.ac: detect SSL in libcurl using curl-config
The API of libcurl does not mention Curl_ssl_init() and when curl is
built with -flto, the Curl_ssl_init symbol is not exported.

https://curl.haxx.se/libcurl/using/ suggests calling

  curl-config --feature | grep SSL

to see, if the installed curl has SSL support.  Another approach
would be calling curl_version_info and checking the returned struct.

This patch removes the check for the Curl_ssl_init exported symbol
from libcurl and uses curl-config to detect SSL support in libcurl.

Signed-off-by: Дилян Палаузов <git-dpa@aegee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-28 09:25:06 -07:00
Junio C Hamano a0c9cf51c0 Merge branch 'ky/imap-send-openssl-1.1.0' into maint
Upcoming OpenSSL 1.1.0 will break compilation b updating a few APIs
we use in imap-send, which has been adjusted for the change.

* ky/imap-send-openssl-1.1.0:
  configure: remove checking for HMAC_CTX_cleanup
  imap-send: avoid deprecated TLSv1_method()
  imap-send: check NULL return of SSL_CTX_new()
  imap-send: use HMAC() function provided by OpenSSL
2016-05-06 14:53:24 -07:00
Junio C Hamano 33e4ec89d9 Merge branch 'ky/imap-send-openssl-1.1.0'
Upcoming OpenSSL 1.1.0 will break compilation b updating a few APIs
we use in imap-send, which has been adjusted for the change.

* ky/imap-send-openssl-1.1.0:
  configure: remove checking for HMAC_CTX_cleanup
  imap-send: avoid deprecated TLSv1_method()
  imap-send: check NULL return of SSL_CTX_new()
  imap-send: use HMAC() function provided by OpenSSL
2016-04-22 15:45:08 -07:00
Kazuki Yamaguchi 1245c74936 configure: remove checking for HMAC_CTX_cleanup
We don't need it, as we no longer use HMAC_CTX_cleanup() directly.

Signed-off-by: Kazuki Yamaguchi <k@rhe.jp>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-08 11:46:36 -07:00
Junio C Hamano 2df13639e7 Merge branch 'jc/sane-grep'
Recent versions of GNU grep is pickier than before to decide if a
file is "binary" and refuse to give line-oriented hits when we
expect it to, unless explicitly told with "-a" option.  As our
scripted Porcelains use sane_grep wrapper for line-oriented data,
even when the line may contain non-ASCII payload we took from
end-user data, use "grep -a" to implement sane_grep wrapper when
using an implementation of "grep" that takes the "-a" option.

* jc/sane-grep:
  rebase-i: clarify "is this commit relevant?" test
  sane_grep: pass "-a" if grep accepts it
2016-03-16 13:16:54 -07:00
Junio C Hamano 71b401032b sane_grep: pass "-a" if grep accepts it
Newer versions of GNU grep is reported to be pickier when we feed a
non-ASCII input and break some Porcelain scripts.  As we know we do
not feed random binary file to our own sane_grep wrapper, allow us
to always pass "-a" by setting SANE_TEXT_GREP=-a Makefile variable
to work it around.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-10 15:35:43 -08:00
Jeff King cd76778049 Merge branch 'rc/configure-use-libs-when-checking-a-lib' into maint
The "configure" script did not test for -lpthread correctly, which
upset some linkers.

* rc/configure-use-libs-when-checking-a-lib:
  configure.ac: use $LIBS not $CFLAGS when testing -lpthread
2015-12-01 17:19:06 -05:00
Jeff King a3824e7145 Merge branch 'rc/configure-use-libs-when-checking-a-lib'
The "configure" script did not test for -lpthread correctly, which
upset some linkers.

* rc/configure-use-libs-when-checking-a-lib:
  configure.ac: use $LIBS not $CFLAGS when testing -lpthread
2015-11-24 19:06:33 -05:00
Rainer M. Canavan bac2c5bf1a configure.ac: use $LIBS not $CFLAGS when testing -lpthread
Some linkers, namely the one on IRIX are rather strict concerning
the order or arguments for symbol resolution, i.e. no libraries
listed before objects or other libraries on the command line are
considered for symbol resolution.  Therefore, -lpthread can't work
if it's put in CFLAGS, because it will not be considered for
resolving pthread_key_create in conftest.o. Use $LIBS instead.

Signed-off-by: Rainer Canavan <git@canavan.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-06 09:41:08 -08:00
Junio C Hamano 9627b0a49f Merge branch 'rp/link-curl-before-ssl'
The linkage order of libraries was wrong in places around libcurl.

* rp/link-curl-before-ssl:
  configure.ac: detect ssl need with libcurl
  Makefile: make curl-config path configurable
  Makefile: link libcurl before zlib
2015-10-29 13:59:20 -07:00
Remi Pommarel 7e91e8d73a configure.ac: detect ssl need with libcurl
When libcurl has been statically compiled with openssl support they both
need to be linked in everytime libcurl is used.

During configuration this can be detected by looking for Curl_ssl_init
function symbol in libcurl, which will only be present if libcurl has been
compiled statically built with openssl.

configure.ac checks for Curl_ssl_init function in libcurl and if such function
exists; it sets NEEDS_SSL_WITH_CURL that is used by the Makefile to include
-lssl alongside with -lcurl.

Signed-off-by: Remi Pommarel <repk@triplefau.lt>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-21 12:44:44 -07:00
Remi Pommarel f89158760d Makefile: make curl-config path configurable
There are situations, e.g. during cross compilation, where curl-config
program is not present in the PATH.

Make the makefile use a configurable curl-config program passed through
CURL_CONFIG variable which can be set through config.mak.

Also make this variable tunable through use of autoconf/configure. Configure
will set CURL_CONFIG variable in config.mak.autogen to whatever value has been
passed to ac_cv_prog_CURL_CONFIG.

Signed-off-by: Remi Pommarel <repk@triplefau.lt>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-21 12:43:31 -07:00
Jeff King e23a91b047 Makefile: drop D_INO_IN_DIRENT build knob
Now that fsck has dropped its inode-sorting, there are no
longer any users of this knob, and it can go away.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-05 11:08:06 -07:00
Eric Sunshine 96658060d7 configure: add getdelim() check
As an optimization, strbuf will take advantage of getdelim() if
available, so add a configure check which defines HAVE_GETDELIM if
found.

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 09:38:19 -07:00
Kyle J. McKay 9529080de2 configure: support HAVE_BSD_SYSCTL option
On BSD-compatible systems some information such as the number
of available CPUs may only be available via the sysctl function.

Add support for a HAVE_BSD_SYSCTL option complete with autoconf
support and include the sys/syctl.h header when the option is
enabled to make the sysctl function available.

Signed-off-by: Kyle J. McKay <mackyle@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-10 15:13:25 -07:00
Reuben Hawkins 88e011814b configure.ac: check for HMAC_CTX_cleanup
OpenSSL version 0.9.6b and before defined the function HMAC_cleanup.
Newer versions define HMAC_CTX_cleanup.  Check for HMAC_CTX_cleanup and
fall back to HMAC_cleanup when the newer function is missing.

Signed-off-by: Reuben Hawkins <reubenhwk@gmail.com>
Reviewed-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-09 15:33:57 -08:00
Reuben Hawkins a6c3c638ac configure.ac: check for clock_gettime and CLOCK_MONOTONIC
Set or clear Makefile variables HAVE_CLOCK_GETTIME and
HAVE_CLOCK_MONOTONIC based upon results of the checks (overriding
default values from config.mak.uname).

CLOCK_MONOTONIC isn't available on RHEL3, but there are still RHEL3
systems being used in production.

Signed-off-by: Reuben Hawkins <reubenhwk@gmail.com>
Reviewed-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-09 15:33:39 -08:00
Reuben Hawkins 8bd2c972b1 configure.ac: check 'tv_nsec' field in 'struct stat'
Detect 'tv_nsec' field in 'struct stat' and set Makefile variable
NO_NSEC appropriately.

A side-effect of the above detection is that we also determine
whether 'stat.st_mtimespec' is available, so, as a bonus, set the
Makefile variable USE_ST_TIMESPEC, as well.

Signed-off-by: Reuben Hawkins <reubenhwk@gmail.com>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Reviewed-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-09 15:33:39 -08:00
Junio C Hamano 2f17ecbd8d Merge branch 'dm/compat-s-ifmt-for-zos'
Long overdue departure from the assumption that S_IFMT is shared by
everybody made in 2005.

* dm/compat-s-ifmt-for-zos:
  compat: convert modes to use portable file type values
2014-12-22 12:27:16 -08:00
David Michael d543d9c0f4 compat: convert modes to use portable file type values
This adds simple wrapper functions around calls to stat(), fstat(),
and lstat() that translate the operating system's native file type
bits to those used by most operating systems.  It also rewrites the
S_IF* macros to the common values, so all file type processing is
performed using the translated modes.  This makes projects portable
across operating systems that use different file type definitions.

Only the file type bits may be affected by these compatibility
functions; the file permission bits are assumed to be 07777 and are
passed through unchanged.

Signed-off-by: David Michael <fedora.dm0@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-04 11:58:36 -08:00
Jonas 'Sortie' Termansen a6fd4fb55d autoconf: check for setitimer()
The Makefile has provisions for this case, so let's detect it in the
configure script as well.

Signed-off-by: Jonas 'Sortie' Termansen <sortie@maxsi.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-29 10:45:32 -07:00
Jonas 'Sortie' Termansen 6441090cf2 autoconf: check for struct itimerval
The Makefile has provisions for this case, so let's detect it in the
configure script as well.

Signed-off-by: Jonas 'Sortie' Termansen <sortie@maxsi.org>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-29 10:39:39 -07:00
Junio C Hamano 8eaf517835 Merge branch 'ks/tree-diff-nway'
Instead of running N pair-wise diff-trees when inspecting a
N-parent merge, find the set of paths that were touched by walking
N+1 trees in parallel.  These set of paths can then be turned into
N pair-wise diff-tree results to be processed through rename
detections and such.  And N=2 case nicely degenerates to the usual
2-way diff-tree, which is very nice.

* ks/tree-diff-nway:
  mingw: activate alloca
  combine-diff: speed it up, by using multiparent diff tree-walker directly
  tree-diff: rework diff_tree() to generate diffs for multiparent cases as well
  Portable alloca for Git
  tree-diff: reuse base str(buf) memory on sub-tree recursion
  tree-diff: no need to call "full" diff_tree_sha1 from show_path()
  tree-diff: rework diff_tree interface to be sha1 based
  tree-diff: diff_tree() should now be static
  tree-diff: remove special-case diff-emitting code for empty-tree cases
  tree-diff: simplify tree_entry_pathcmp
  tree-diff: show_path prototype is not needed anymore
  tree-diff: rename compare_tree_entry -> tree_entry_pathcmp
  tree-diff: move all action-taking code out of compare_tree_entry()
  tree-diff: don't assume compare_tree_entry() returns -1,0,1
  tree-diff: consolidate code for emitting diffs and recursion in one place
  tree-diff: show_tree() is not needed
  tree-diff: no need to pass match to skip_uninteresting()
  tree-diff: no need to manually verify that there is no mode change for a path
  combine-diff: move changed-paths scanning logic into its own function
  combine-diff: move show_log_first logic/action out of paths scanning
2014-06-03 12:06:40 -07:00
Kirill Smelkov 61f76a3612 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 11:54:01 -07:00
Junio C Hamano 2f2db83fb7 Merge branch 'dm/configure-iconv-locale-charset'
* dm/configure-iconv-locale-charset:
  configure.ac: link with -liconv for locale_charset()
2014-03-25 11:07:51 -07:00
Dmitry Marakasov 62fb6d03da configure.ac: link with -liconv for locale_charset()
On e.g. FreeBSD 10.x, the following situation is common:
- there's iconv implementation in libc, which has no locale_charset()
  function
- there's GNU libiconv installed from Ports Collection

Git build process
- detects that iconv is in libc and thus -liconv is not needed for it
- detects locale_charset in -liconv, but for some reason doesn't add it
  to CHARSET_LIB (as it would do with -lcharset if locale_charset() was
  found there instead of -liconv)
- git doesn't build due to unresolved external locale_charset()

Fix this by adding -liconv to CHARSET_LIB if locale_charset() is
detected in this library.

Signed-off-by: Dmitry Marakasov <amdmi3@amdmi3.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-11 13:33:15 -07:00