|
d1036201
|
2022-06-18T16:10:38
|
|
meta: generated `features.h` is now `git2_features.h`
Linux has a /usr/include/features.h, which gets confusing; update this
to `git2_features.h` and move it into the `util` directory.
|
|
96c61174
|
2022-06-13T11:19:55
|
|
cmake: only use `getloadavg` where it exists
|
|
3809ab0e
|
2022-06-13T10:50:40
|
|
cmake: add `gnu` library for Haiku
|
|
9bc82c8f
|
2022-06-13T10:46:21
|
|
cmake: detect `getentropy`
Look for `getentropy` and flag its existence.
|
|
3a3ab065
|
2020-05-03T23:13:28
|
|
cli: infrastructure for a cli project
Introduce a command-line interface for libgit2. The goal is for it to
be git-compatible.
1. The libgit2 developers can more easily dogfood libgit2 to find bugs,
and performance issues.
2. There is growing usage of libgit2's examples as a client; libgit2's
examples should be exactly that - simple code samples that illustrate
libgit2's usage. This satisfies that need directly.
3. By producing a client ourselves, we can better understand the needs
of client creators, possibly producing a shared "middleware" for
commonly-used pieces of client functionality like interacting with
external tools.
4. Since git is the reference implementation, we may be able to benefit
from git's unit tests, running their test suite against our CLI to
ensure correct behavior.
This commit introduces a simple infrastructure for the CLI.
The CLI is currently links libgit2 statically; this is because the
utility layer is required for libgit2 _but_ shares the error state
handling with libgit2 itself. There's no obviously good solution
here without introducing annoying indirection or more complexity.
Until we can untangle that dependency, this is a good step forward.
In the meantime, we link the libgit2 object files, but we do not include
the (private) libgit2 headers. This constrains the CLI to the public
libgit2 interfaces.
|
|
3344fddc
|
2021-11-16T23:29:22
|
|
refactor: `tests` is now `tests/libgit2`
Like we want to separate libgit2 and utility source code, we want to
separate libgit2 and utility tests. Start by moving all the tests into
libgit2.
|
|
c3b7ace9
|
2021-11-14T16:43:53
|
|
refactor: make util an object library
Instead of simply including the utility files directly, make them a
cmake object library for easy reusability between other projects within
libgit2.
Now the top-level `src` is responsible for platform selection, while the
next-level `libgit2` and `util` configurations are responsible for
identifying what objects they include.
|
|
ef4ab298
|
2021-11-14T08:47:40
|
|
refactor: `src` is now `src/libgit2`
|
|
3c53796c
|
2022-02-07T19:38:32
|
|
rand: introduce git_rand PRNG
Introduce `git_rand`, a PRNG based on xoroshiro256**, a fast,
all-purpose pseudo-random number generator: https://prng.di.unimi.it
The PRNG will be seeded by the system's entropy store when possible,
falling back to current time and system data (pid, uptime, etc).
Inspiration for this was taken from libressl, but since our PRNG is
not used for cryptographic purposes (and indeed currently only generates
a unique temp file name that is written in a protected directory),
this should be more than sufficient.
Our implementation of xoroshiro256** was taken almost strictly from
the original author's sources, but was tested against PractRand to
ensure that there were no foolish mistranslations:
```
RNG_test using PractRand version 0.94
RNG = RNG_stdin64, seed = unknown
test set = core, folding = standard (64 bit)
rng=RNG_stdin64, seed=unknown
length= 256 megabytes (2^28 bytes), time= 2.9 seconds
no anomalies in 210 test result(s)
rng=RNG_stdin64, seed=unknown
length= 512 megabytes (2^29 bytes), time= 6.2 seconds
no anomalies in 226 test result(s)
rng=RNG_stdin64, seed=unknown
length= 1 gigabyte (2^30 bytes), time= 12.7 seconds
no anomalies in 243 test result(s)
rng=RNG_stdin64, seed=unknown
length= 2 gigabytes (2^31 bytes), time= 25.4 seconds
no anomalies in 261 test result(s)
rng=RNG_stdin64, seed=unknown
length= 4 gigabytes (2^32 bytes), time= 50.6 seconds
no anomalies in 277 test result(s)
rng=RNG_stdin64, seed=unknown
length= 8 gigabytes (2^33 bytes), time= 104 seconds
no anomalies in 294 test result(s)
```
|
|
18a477e7
|
2022-02-02T22:35:07
|
|
Merge pull request #6195 from libgit2/ethomson/zdiff3
merge: support zdiff3 conflict styles
|
|
34e01bd2
|
2022-01-20T23:07:05
|
|
cmake: disable some gnu extensions
|
|
1458fb56
|
2022-01-29T07:18:26
|
|
xdiff: include new xdiff from git
Update to the xdiff used in git v2.35.0, with updates to our build
configuration to ignore the sort of warnings that we normally care
about (signed/unsigned mismatch, unused, etc.)
Any git-specific abstraction bits are now redefined for our use in
`git-xdiff.h`. It is a (wildly optimistic) hope that we can use that
indirection layer to standardize on a shared xdiff implementation.
|
|
c5cd71b2
|
2021-12-23T18:23:34
|
|
cmake: use PROJECT_SOURCE_DIR of CMAKE_SOURCE_DIR
Also applies to *_BINARY_DIR.
This effectively reverts 84083dcc8bd41332ccac9d7b537f3e254d79011c,
which broke all users of libgit2 that use it as a CMake subdirectory
(via `add_subdirectory()`). This is because CMAKE_SOURCE_DIR refers
to the root-most CMake directory, which in the case of
`add_subdirectory()` is a parent project to libgit2 and thus the paths
don't make any sense to the configuration files. Corollary,
CMAKE_SOURCE_DIR only makes sense if the CMake project is always the
root project - which can rarely be guaranteed.
In all honesty, CMake should deprecate and eventually remove
CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR. It's been the source of headaches
and confusion for years, they're rarely useful over
CMAKE_CURRENT_(SOURCE|BINARY)_DIR or PROJECT_(SOURCE|BINARY)_DIR,
and they cause a lot of confusing configuration and source
code layouts to boot.
Any time they are used, they break `add_subdirectory()` almost 100% of
the time, cause confusing error messages, and hide subtle bugs.
|
|
84083dcc
|
2021-11-19T08:48:08
|
|
cmake: use CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR
Instead of using the project-specific `libgit2_SOURCE_DIR` and
`libgit2_BINARY_DIR` variables, use `CMAKE_SOURCE_DIR` and
`CMAKE_BINARY_DIR`.
|
|
2c154145
|
2021-11-11T23:09:44
|
|
cmake: move sha1 source selection into CMakeLists.txt
The select hashes module selects the hash; the CMakeLists.txt selects
the files to implement it.
|
|
395b3dc4
|
2021-11-11T22:10:51
|
|
cmake: refactor global variables
Update the global variables `LIBGIT2_OBJECTS` to
`LIBGIT2_DEPENDENCY_OBJECTS` for clarity and consistency.
|
|
4a6ef5a4
|
2021-11-11T17:04:24
|
|
cmake: move missing-declarations warning to top-level
We should enforce declarations throughout the code-base, including
examples, fuzzers and tests, not just in the `src` tree.
|
|
4e84ddd5
|
2021-11-10T21:59:46
|
|
cmake: refactor zlib selection
Move zlib selection into its own cmake module.
|
|
83fa5480
|
2021-11-10T21:58:12
|
|
cmake: refactor WinHTTP selection
Move WinHTTP selection into its own cmake module.
|
|
e35a22a0
|
2021-11-10T21:55:23
|
|
cmake: refactor libssh2 selection
Move SSH selection into its own cmake module.
|
|
f0cb3788
|
2021-11-10T21:51:55
|
|
cmake: refactor regex selection
Move regex selection into its own cmake module.
|
|
de178d36
|
2021-11-10T21:49:20
|
|
cmake: refactor http_parser selection
Move http_parser selection into its own cmake module.
|
|
16b6e3a9
|
2021-11-10T21:33:28
|
|
cmake: HTTP_Parser is now HTTPParser
|
|
19e99de0
|
2021-11-10T08:14:11
|
|
cmake: qsort detection in features.h
|
|
7b527c12
|
2021-11-06T16:38:11
|
|
cmake: move deprecation definition to src/
There's no need to add the deprecation at the top-level. Our tests add
deprecation explicitly.
|
|
789ab915
|
2021-11-10T21:02:42
|
|
cmake: standardize USE_WINHTTP
WinHTTP can now be disabled with `USE_WINHTTP=OFF` instead of
`WINHTTP=OFF` to better support the other cmake semantics.
|
|
9324d16e
|
2021-11-06T16:14:47
|
|
cmake: standardize USE_THREADS and USE_NSEC
Threading can now be disabled with `USE_THREADS=OFF` instead of
`THREADSAFE=OFF` to better support the other cmake semantics.
Nanosecond support is the default _if_ we can detect it. This should be
our default always - like threads - and people can opt out explicitly.
|
|
52693ab4
|
2021-09-26T23:11:13
|
|
cmake: stylistic refactoring
Ensure that we always use lowercase function names, and that we do not
have spaces preceding open parentheses, for consistency.
|
|
8507bf81
|
2021-09-26T21:54:08
|
|
trace: always enabled
There's no need to make tracing opt-in; it should always be included.
|
|
413bfb83
|
2021-09-14T13:53:29
|
|
Update src/CMakeLists.txt
Co-authored-by: Edward Thomson <ethomson@github.com>
|
|
0a3a220f
|
2021-09-14T09:53:24
|
|
Discover libssh2 without pkg-config
|
|
0850b172
|
2021-08-25T12:20:50
|
|
Merge pull request #5950 from boretrk/posixtest
open: input validation for empty segments in path
|
|
2dbe413e
|
2021-08-17T11:34:11
|
|
Fix LIBGIT2_FILENAME not being passed to the resource compiler
|
|
e96fc028
|
2021-08-08T13:22:53
|
|
tests: optional test for p_open() with empty path segments
|
|
3062a633
|
2021-07-30T12:03:35
|
|
cmake: extended futimens checking on macOS
|
|
48e6b02b
|
2021-07-19T15:41:44
|
|
alloc: add GIT_DEBUG_STRICT_ALLOC
Add `GIT_DEBUG_STRICT_ALLOC` to help identify problematic callers of
allocation code that pass a `0` size to the allocators and then expect a
non-`NULL` return.
When given a 0-size allocation, `malloc` _may_ return either a `NULL`
_or_ a pointer that is not writeable. Most systems return a non-`NULL`
pointer; AIX is an outlier. We should be able to cope with this AIXy
behavior, so this adds an option to emulate it.
|
|
754fa526
|
2021-01-04T06:10:10
|
|
Use an option instead of a flag for USE_BUNDLED_ZLIB
Now `USE_BUNDLED_ZLIB` can be set to the string `Chromium` to enable the
Chromium implementation of zlib.
|
|
83265b3e
|
2020-12-18T06:50:22
|
|
zlib: Add support for building with Chromium's zlib implementation
This change builds libgit2 using Chromium's zlib implementation by
invoking cmake with `-DUSE_BUNDLED_ZLIB=ON -DUSE_CHROMIUM_ZLIB=ON`,
which is ~10% faster than the bundled zlib for the core::zstream suite.
This version of zlib has some optimizations:
a) Decompression (Intel+ARM): inflate_fast, adler32, crc32, etc.
b) Compression (Intel): fill_window, longest_match, hash function, etc.
Due to the introduction of SIMD optimizations, and to get the maximum
performance out of this fork of zlib, this requires an x86_64 processor
with SSE4.2 and CLMUL (anything Westmere or later, ~2010). The Chromium
zlib implementation also supports ARM with NEON, but it has not been
enabled in this patch.
Performance
===========
TL;DR: Running just `./libgit2_clar -score::zstream` 100 times in a loop
took 0:56.30 before and 0:50.67 after (~10% reduction!).
The bundled and system zlib implementations on an Ubuntu Focal system
perform relatively similar (the bundled one is marginally better due to
the compiler being able to inline some functions), so only the bundled
and Chromium zlibs were compared.
For a more balanced comparison (to ensure that nothing regressed
overall), `libgit2_clar` under `perf` was also run, and the zlib-related
functions were compared.
Bundled
-------
```shell
cmake \
-DUSE_BUNDLED_ZLIB=ON \
-DUSE_CHROMIUM_ZLIB=OFF \
-DCMAKE_BUILD_TYPE="RelWithDebInfo" \
-DCMAKE_C_FLAGS="-fPIC -fno-omit-frame-pointer" \
-GNinja \
..
ninja
perf record --call-graph=dwarf ./libgit2_clar
perf report --children
```
```
Samples: 87K of event 'cycles', Event count (approx.): 75923450603
Children Self Command Shared Objec Symbol
+ 4.14% 0.01% libgit2_clar libgit2_clar [.] git_zstream_get_output_chunk
+ 2.91% 0.00% libgit2_clar libgit2_clar [.] git_zstream_get_output
+ 0.69% 0.00% libgit2_clar libgit2_clar [.] git_zstream_get_output (inlined)
0.17% 0.00% libgit2_clar libgit2_clar [.] git_zstream_init
0.02% 0.00% libgit2_clar libgit2_clar [.] git_zstream_reset
0.00% 0.00% libgit2_clar libgit2_clar [.] git_zstream_eos
0.00% 0.00% libgit2_clar libgit2_clar [.] git_zstream_done
0.00% 0.00% libgit2_clar libgit2_clar [.] git_zstream_free (inlined)
Samples: 87K of event 'cycles', Event count (approx.): 75923450603
Children Self Command Shared Objec Symbol
+ 3.12% 0.01% libgit2_clar libgit2_clar [.] deflate
+ 2.65% 1.48% libgit2_clar libgit2_clar [.] deflate_slow
+ 1.60% 0.55% libgit2_clar libgit2_clar [.] inflate
+ 0.53% 0.00% libgit2_clar libgit2_clar [.] write_deflate
0.49% 0.36% libgit2_clar libgit2_clar [.] inflate_fast
0.46% 0.02% libgit2_clar libgit2_clar [.] deflate_fast
0.19% 0.19% libgit2_clar libgit2_clar [.] inflate_table
0.16% 0.01% libgit2_clar libgit2_clar [.] inflateInit_
0.15% 0.00% libgit2_clar libgit2_clar [.] inflateInit2_ (inlined)
0.10% 0.00% libgit2_clar libgit2_clar [.] deflateInit_
0.10% 0.00% libgit2_clar libgit2_clar [.] deflateInit2_
0.03% 0.00% libgit2_clar libgit2_clar [.] deflateReset (inlined)
0.02% 0.00% libgit2_clar libgit2_clar [.] deflateReset
0.02% 0.00% libgit2_clar libgit2_clar [.] inflateEnd
0.02% 0.00% libgit2_clar libgit2_clar [.] deflateEnd
0.01% 0.00% libgit2_clar libgit2_clar [.] deflateResetKeep
0.01% 0.01% libgit2_clar libgit2_clar [.] inflateReset2
0.01% 0.00% libgit2_clar libgit2_clar [.] deflateReset (inlined)
0.00% 0.00% libgit2_clar libgit2_clar [.] inflateStateCheck (inlined)
0.00% 0.00% libgit2_clar libgit2_clar [.] inflateReset (inlined)
0.00% 0.00% libgit2_clar libgit2_clar [.] inflateStateCheck (inlined)
0.00% 0.00% libgit2_clar libgit2_clar [.] deflateStateCheck (inlined)
0.00% 0.00% libgit2_clar libgit2_clar [.] inflateResetKeep (inlined)
```
Chromium
--------
```shell
cmake \
-DUSE_BUNDLED_ZLIB=ON \
-DUSE_CHROMIUM_ZLIB=ON \
-DCMAKE_BUILD_TYPE="RelWithDebInfo" \
-DCMAKE_C_FLAGS="-fPIC -fno-omit-frame-pointer" \
-GNinja \
..
ninja
perf record --call-graph=dwarf ./libgit2_clar
perf report --children
```
```
Samples: 97K of event 'cycles', Event count (approx.): 80862210917
Children Self Command Shared Objec Symbol
+ 3.31% 0.00% libgit2_clar libgit2_clar [.] git_zstream_get_output_chunk
+ 2.27% 0.01% libgit2_clar libgit2_clar [.] git_zstream_get_output
+ 0.55% 0.00% libgit2_clar libgit2_clar [.] git_zstream_get_output (inlined)
0.18% 0.00% libgit2_clar libgit2_clar [.] git_zstream_init
0.02% 0.00% libgit2_clar libgit2_clar [.] git_zstream_reset
0.00% 0.00% libgit2_clar libgit2_clar [.] git_zstream_free (inlined)
0.00% 0.00% libgit2_clar libgit2_clar [.] git_zstream_done
0.00% 0.00% libgit2_clar libgit2_clar [.] git_zstream_free
Samples: 97K of event 'cycles', Event count (approx.): 80862210917
Children Self Command Shared Objec Symbol
+ 2.55% 0.01% libgit2_clar libgit2_clar [.] deflate
+ 2.25% 1.41% libgit2_clar libgit2_clar [.] deflate_slow
+ 1.10% 0.52% libgit2_clar libgit2_clar [.] inflate
0.36% 0.00% libgit2_clar libgit2_clar [.] write_deflate
0.30% 0.03% libgit2_clar libgit2_clar [.] deflate_fast
0.28% 0.15% libgit2_clar libgit2_clar [.] inflate_fast_chunk_
0.19% 0.19% libgit2_clar libgit2_clar [.] inflate_table
0.17% 0.01% libgit2_clar libgit2_clar [.] inflateInit_
0.16% 0.00% libgit2_clar libgit2_clar [.] inflateInit2_ (inlined)
0.15% 0.00% libgit2_clar libgit2_clar [.] deflateInit_
0.15% 0.00% libgit2_clar libgit2_clar [.] deflateInit2_
0.11% 0.01% libgit2_clar libgit2_clar [.] adler32_z
0.09% 0.09% libgit2_clar libgit2_clar [.] adler32_simd_
0.05% 0.00% libgit2_clar libgit2_clar [.] deflateReset (inlined)
0.05% 0.00% libgit2_clar libgit2_clar [.] deflate_read_buf
0.03% 0.00% libgit2_clar libgit2_clar [.] inflateEnd
0.02% 0.00% libgit2_clar libgit2_clar [.] deflateReset
0.01% 0.00% libgit2_clar libgit2_clar [.] deflateEnd
0.01% 0.01% libgit2_clar libgit2_clar [.] inflateReset2
0.01% 0.00% libgit2_clar libgit2_clar [.] inflateReset (inlined)
0.00% 0.00% libgit2_clar libgit2_clar [.] adler32
0.00% 0.00% libgit2_clar libgit2_clar [.] inflateResetKeep (inlined)
0.00% 0.00% libgit2_clar libgit2_clar [.] deflateResetKeep
0.00% 0.00% libgit2_clar libgit2_clar [.] inflateStateCheck (inlined)
0.00% 0.00% libgit2_clar libgit2_clar [.] inflateStateCheck (inlined)
0.00% 0.00% libgit2_clar libgit2_clar [.] inflateStateCheck (inlined)
0.00% 0.00% libgit2_clar libgit2_clar [.] deflateStateCheck (inlined)
```
|
|
4218403e
|
2020-06-05T10:49:09
|
|
cmake: use target-specific compile definitions
We set up some compile definitions as part of our src/CMakeLists.txt.
While the definitions are global, we really only need them as part of
the git2internal target which compiles all the objects. Let's thus use
`target_compile_definitions` instead of `add_definitions`.
|
|
53911edd
|
2020-06-05T10:24:30
|
|
cmake: use git2internal target to populate sources
Modern CMake is usually target-driven in that a target is first defined
and then the likes of `target_sources`, `target_include_directories`
etc. are used to further populate the target. We still use old-style
CMake, where we first set up a set of variables and then populate the
target in a single call.
Let's migrate to modern CMake usage by starting to populate the sources
of our git2internal target piece-by-piece. While this is a small step,
it allows us to convert to target-based build instructions
piece-by-piece.
|
|
19eb1e4b
|
2020-06-05T10:07:33
|
|
cmake: specify project version
We currently do not set up a project version within CMake, meaning that
it can't be use by other projects including libgit2 as a sub-project and
also not by other tools like IDEs.
This commit changes this to always set up a project version, but instead
of extracting it from the "version.h" header we now set it up directly.
This is mostly to avoid mis-use of the previous `LIBGIT2_VERSION`
variables, as we should now always use the `libgit2_VERSION` ones that
are set up by CMake if one provides the "VERSION" keyword to the
`project()` call. While this is one more moving target we need to adjust
on releases, this commit also adjusts our release script to verify that
the project version was incremented as expected.
|
|
dc1deb3b
|
2020-07-01T15:41:38
|
|
Use __GNUC__ macro in the resource script
Fix the default LIBGIT2_FILENAME for GNU windres
|
|
5c40456b
|
2020-06-16T13:19:02
|
|
Enable building git2.rc resource script with GCC
|
|
03c4f86c
|
2020-06-08T12:42:59
|
|
cmake: enable warnings for missing function declarations
Over time, we have accumulated quite a lot of functions with missing
prototypes, missing `static` keywords or which were completely unused.
It's easy to miss these mistakes, but luckily GCC and Clang both have
the `-Wmissing-declarations` warning. Enabling this will cause them to
emit warnings for every not-static function that doesn't have a previous
declaration. This is a very sane thing to enable, and with the preceding
commits all these new warnings have been fixed.
So let's always enable this warning so we won't introduce new instances
of them.
|
|
b85eefb4
|
2020-05-15T19:52:40
|
|
cmake: Sort source files for reproducible builds
We currently use `FILE(GLOB ...)` in most places to find source and
header files. This is problematic in that the order of files returned
depends on the operating system's directory iteration order and may thus
not be deterministic. As a result, we link object files in unspecified
order, which may cause the linker to emit different code across runs.
Fix this issue by sorting all code used as input to the libgit2 library
to improve the reliability of reproducible builds.
|
|
9a102446
|
2020-03-21T16:49:44
|
|
Merge pull request #5455 from pks-t/pks/cmake-install-dirs
cmake: use install directories provided via GNUInstallDirs
|
|
87fc539f
|
2020-03-13T22:08:19
|
|
cmake: use install directories provided via GNUInstallDirs
We currently hand-code logic to configure where to install our artifacts
via the `LIB_INSTALL_DIR`, `INCLUDE_INSTALL_DIR` and `BIN_INSTALL_DIR`
variables. This is reinventing the wheel, as CMake already provide a way
to do that via `CMAKE_INSTALL_<DIR>` paths, e.g. `CMAKE_INSTALL_LIB`.
This requires users of libgit2 to know about the discrepancy and will
require special hacks for any build systems that handle these variables
in an automated way. One such example is Gentoo Linux, which sets up
these paths in both the cmake and cmake-utils eclass.
So let's stop doing that: the GNUInstallDirs module handles it in a
better way for us, especially so as the actual values are dependent on
CMAKE_INSTALL_PREFIX. This commit removes our own set of variables and
instead refers users to use the standard ones.
As a second benefit, this commit also fixes our pkgconfig generation to
use the GNUInstallDirs module. We had a bug there where we ignored the
CMAKE_INSTALL_PREFIX when configuring the libdir and includedir keys, so
if libdir was set to "lib64", then libdir would be an invalid path. With
GNUInstallDirs, we can now use `CMAKE_INSTALL_FULL_LIBDIR`, which
handles the prefix for us.
|
|
b1f6481f
|
2020-03-10T22:07:35
|
|
cmake: ignore deprecation notes for Secure Transport
The Secure Transport interface we're currently using has been deprecated
with macOS 10.15. As we're currently in code freeze, we cannot migrate
to newer interfaces. As such, let's disable deprecation warnings for
our "schannel.c" stream.
|
|
e23b8b44
|
2020-03-06T17:13:48
|
|
Merge pull request #5422 from pks-t/pks/cmake-booleans
CMake booleans
|
|
dd704944
|
2020-03-03T11:05:04
|
|
Set proper pkg-config dependency for pcre2
Signed-off-by: Igor Raits <i.gnatenko.brain@gmail.com>
|
|
d8e71cb2
|
2020-02-24T21:07:34
|
|
cmake: fix ENABLE_TRACE parameter being too strict
In order to check whether tracing support should be turned on, we check
whether ENABLE_TRACE equals "ON". This is being much too strict, as
CMake will also treat "on", "true", "yes" and others as true-ish, but
passing them will disable tracing support now.
Fix the issue by simply removing the STREQUAL, which will cause CMake to
do the right thing automatically.
|
|
877054f3
|
2020-02-10T12:35:13
|
|
cmake: consolidate Valgrind option
OpenSSL doesn't initialize bytes on purpose in order to generate
additional entropy. Valgrind isn't too happy about that though, causing
it to generate warninings about various issues regarding use of
uninitialized bytes.
We traditionally had some infrastructure to silence these errors in our
OpenSSL stream implementation, where we invoke the Valgrind macro
`VALGRIND_MAKE_MEMDEFINED` in various callbacks that we provide to
OpenSSL. Naturally, we only include these instructions if a preprocessor
define "VALGRIND" is set, and that in turn is only set if passing
"-DVALGRIND" to CMake. We do that in our usual Azure pipelines, but we
in fact forgot to do this in our nightly build. As a result, we get a
slew of warnings for these nightly builds, but not for our normal
builds.
To fix this, we could just add "-DVALGRIND" to our nightly builds. But
starting with commit d827b11b6 (tests: execute leak checker via CTest
directly, 2019-06-28), we do have a secondary variable that directs
whether we want to use memory sanitizers for our builds. As such, every
user wishing to use Valgrind for our tests needs to pass both options
"VALGRIND" and "USE_LEAK_CHECKER", which is cumbersome and error prone,
as can be seen by our own builds.
Instead, let's consolidate this into a single option, removing the old
"-DVALGRIND" one. Instead, let's just add the preprocessor directive if
USE_LEAK_CHECKER equals "valgrind" and remove "-DVALGRIND" from our own
pipelines.
|
|
cb77423f
|
2019-11-24T16:22:31
|
|
valgrind: add valgrind hints in OpenSSL
Provide usage hints to valgrind. We trust the data coming back from
OpenSSL to have been properly initialized. (And if it has not, it's an
OpenSSL bug, not a libgit2 bug.)
We previously took the `VALGRIND` option to CMake as a hint to disable
mmap. Remove that; it's broken. Now use it to pass on the `VALGRIND`
definition so that sources can provide valgrind hints.
|
|
dbc17a7e
|
2019-09-21T08:46:08
|
|
negotiate: use GSS.framework on macOS
|
|
ebabb88f
|
2019-10-10T09:25:32
|
|
cmake: update minimum CMake version to v3.5.1
Back in commit cf9f34521 (cmake: bump minimum version to 2.8.11,
2017-09-06), we have bumped the minimum CMake version to require at
least v2.8.11. The main hold-backs back then were distributions like
RHEL/CentOS as well as Ubuntu Trusty, which caused us to not target a
more modern version. Nowadays, Ubuntu Trusty has been EOL'd and CentOS 6
has CMake v3.6.1 available via the EPEL6 repository, and thus it seems
fair to upgrade to a more recent version.
Going through repology [1], one can see that all supported mainstream
distributions do in fact have CMake 3 available. Going through the list,
the minimum version that is supported by all mainstream distros is in
fact v3.5.1:
- CentOS 6 via EPEL6: 3.6.1
- Debian Oldstable: 3.7.2
- Fedora 26: 3.8.2
- OpenMandriva 3.x: 3.5.1
- Slackware 14.2: 3.5.2
- Ubuntu 16.04: 3.5.1
Consequentally, let's upgrade CMake to the minimum version of 3.5.1 and
remove all the version CMake checks that aren't required anymore.
[1]: https://repology.org/project/cmake/versions
|
|
564b3ffc
|
2019-08-17T12:34:59
|
|
cmake: add missing requires to the .pc file
|
|
d80d9d56
|
2019-08-17T12:17:21
|
|
cmake: streamline *.pc file handling via a module
|
|
071750a3
|
2019-08-15T14:18:26
|
|
cmake: move _WIN32_WINNT definitions to root
|
|
cc9e47c9
|
2019-06-15T18:51:40
|
|
win32: support upgrading warnings to errors (/WX)
For MSVC, support warnings as errors by providing the /WX compiler
flags. (/WX is the moral equivalent of -Werror.)
Disable warnings as errors ass part of xdiff, since it contains
warnings. But as a component of git itself, we want to avoid skew and
keep our implementation as similar as possible to theirs. We'll work
with upstream to fix these issues, but in the meantime, simply let those
continue to warn.
|
|
94fc83b6
|
2019-06-13T16:48:35
|
|
cmake: Modulize our TLS & hash detection
The interactions between `USE_HTTPS` and `SHA1_BACKEND` have been
streamlined. Previously we would have accepted not quite working
configurations (like, `-DUSE_HTTPS=OFF -DSHA1_BACKEND=OpenSSL`) and, as
the OpenSSL detection only ran with `USE_HTTPS`, the link would fail.
The detection was moved to a new `USE_SHA1`, modeled after `USE_HTTPS`,
which takes the values "CollisionDetection/Backend/Generic", to better
match how the "hashing backend" is selected, the default (ON) being
"CollisionDetection".
Note that, as `SHA1_BACKEND` is still used internally, you might need to
check what customization you're using it for.
|
|
fb529a01
|
2019-06-11T22:03:29
|
|
http-parser: use our bundled http-parser by default
Our bundled http-parser includes bugfixes, therefore we should prefer
our http-parser until such time as we can identify that the system
http-parser has these bugfixes (using a version check).
Since these bugs are - at present - minor, retain the ability for users
to force that they want to use the system http-parser anyway. This does
change the cmake specification so that people _must_ opt-in to the new
behavior knowingly.
|
|
a7f65f03
|
2019-03-21T15:42:57
|
|
ntlm: add ntlmclient as a dependency
Include https://github.com/ethomson/ntlmclient as a dependency.
|
|
3d9e82fd
|
2019-05-21T14:59:55
|
|
Merge pull request #4935 from libgit2/ethomson/pcre
Use PCRE for our fallback regex engine when regcomp_l is unavailable
|
|
ac2b235e
|
2019-05-21T12:22:40
|
|
regex: use REGEX_BACKEND as the cmake option name
This avoids any misunderstanding with the REGEX keyword in cmake.
|
|
ada1cd01
|
2019-05-21T21:35:57
|
|
Use tabs for indentation (#5079).
|
|
b575c242
|
2019-05-21T20:20:04
|
|
Fix indentation (#5079).
|
|
2c2e924b
|
2019-05-21T20:17:48
|
|
We still need to update pkgconfig variables when zlib is unbundled (#5079).
|
|
06dbf734
|
2019-05-21T15:44:32
|
|
We've already added `ZLIB_LIBRARIES` to `LIBGIT2_LIBS` so don't also add the `z` library (libgit2/#5079).
|
|
ce6d624a
|
2019-05-19T10:30:04
|
|
regex: optionally use PCRE2
Use PCRE2 and its POSIX compatibility layer if requested by the user.
Although PCRE2 is adequate for our needs, the PCRE2 POSIX layer as
installed on Debian and Ubuntu systems is broken, so we do not opt-in to
it by default to avoid breaking users on those platforms.
|
|
69ecdad5
|
2019-05-19T10:09:55
|
|
regex: use system PCRE if available
Attempt to locate a system-installed version of PCRE and use its POSIX
compatibility layer, if possible.
|
|
622166c4
|
2019-05-18T19:37:59
|
|
regex: disambiguate builtin vs system pcre
|
|
c6e48fef
|
2019-02-17T21:51:34
|
|
regex: allow regex selection in cmake
Users can now select which regex implementation they want to use: one of
the system `regcomp_l`, the system PCRE, the builtin PCRE or the
system's `regcomp`.
By default the system `regcomp_l` will be used if it exists, otherwise
the system PCRE will be used. If neither of those exist, then the
builtin PCRE implementation will be used.
The system's `regcomp` is not used by default due to problems with
locales.
|
|
9ceafb57
|
2019-01-12T22:55:31
|
|
regexec: use pcre as our fallback/builtin regex
Use PCRE 8.42 as the builtin regex implementation, using its POSIX
compatibility layer. PCRE uses ASCII by default and the users locale
will not influence its behavior, so its `regcomp` implementation is
similar to `regcomp_l` with a C locale.
|
|
ee3d71fb
|
2019-04-26T08:01:56
|
|
cmake: fix include ordering issues with bundled deps
When linking against bundled libraries, we include their header
directories by using "-isystem". The reason for that is that we
want to handle our vendored library headers specially, most
importantly to ignore warnings generated by including them. By
using "-isystem", though, we screw up the order of searched
include directories by moving those bundled dependencies towards
the end of the lookup order. Like this, chances are high that any
other specified include directory contains a file that collides
with the actual desired include file.
Fix this by not treating the bundled dependencies' include
directories as system includes. This will move them to the front
of the lookup order and thus cause them to override
system-provided headers. While this may cause the compiler to
generate additional warnings when processing bundled headers,
this is a tradeoff we should make regardless to fix builds on
systems hitting this issue.
|
|
13cb9f7a
|
2019-02-25T11:35:16
|
|
cmake: correctly detect if system provides `regcomp`
We assume that if we are on Win32, Amiga OS, Solaris or SunOS,
that the regcomp(3P) function cannot be provided by the system.
Thus we will in these cases always include our own, bundled regex
sources to make a regcomp implementation available. This test is
obviously very fragile, and we have seen it fail on MSYS2/MinGW
systems, which do in fact provide the regcomp symbol. The effect
is that during compilation, we will use the "regex.h" header
provided by MinGW, but use symbols provided by ourselves. This
in fact may cause subtle memory layout issues, as the structure
made available via MinGW doesn't match what our bundled code
expects.
There's one more problem with our regex detection: on the listed
platforms, we will incorrectly include the bundled regex code
even in case where the system provides regcomp_l(3), but it will
never be used for anything.
Fix the issue by improving our regcomp detection code. Instead of
relying on a fragile listing of platforms, we can just use
`CHECK_FUNCTION_EXISTS` instead. This will not in fact avoid the
header-ordering problem. But we can assume that as soon as a
system-provided "regex.h" header is provided, that
`CHECK_FUNCTION_EXISTS` will now correctly find the desired
symbol and thus not include our bundled regex code.
|
|
b63396b7
|
2019-02-21T12:13:59
|
|
allocators: move standard allocator into subdirectory
Right now, our two allocator implementations are scattered around
the tree in "stdalloc.h" and "win32/w32_crtdbg_stacktrace.h".
Start grouping them together in a single directory "allocators/",
similar to how e.g. our streams are organized.
|
|
21142c5a
|
2018-10-29T10:04:48
|
|
http: remove cURL
We previously used cURL to support HTTP proxies. Now that we've added
this support natively, we can remove the curl dependency.
|
|
b8bdffb5
|
2018-07-02T07:27:09
|
|
cmake: increase WIN32_WINNT to Vista
Increase the WIN32_WINNT level to 0x0600, which enables support for new
APIs from Windows 6.0 (Vista). We had previously set this to 0x0501,
which was Windows XP. Although we removed XP support many years ago,
there was no need to update this level previously. We're doing so now
explicitly so that we can get support for the `CreateSymbolicLink` API.
|
|
1a9cc182
|
2018-08-17T15:56:30
|
|
util: make the qsort_r check work on macOS
This performs a compile-check by using CMake support, to differentiate the GNU
version from the BSD version of qsort_r.
Module taken from 4f252abea5f1d17c60f6ff115c9c44cc0b6f1df6, which I've checked
against CMake 2.8.11.
|
|
e1a4a8eb
|
2018-06-25T11:58:34
|
|
cmake: enforce C90 standard
While the aim of libgit2 was to conform to C90 code, we never instructed
the compiler to enforce C90 compliance. Thus, quite a few violations
were able to get into our code base, which have been removed with the
previous commits. As we are now able to build libgit2 with C90 enforced,
we can set the C_STANDARD property for our own build targets.
Note that we explicitly avoid setting the C standard for our third-party
dependencies. At least the zlib target does not build with C90 enforced,
and we do not want to fix them by deviating from upstream. Thus we
simply enforce no standard for them.
|
|
c13e56f9
|
2018-06-25T14:12:53
|
|
cmake: distinguish internal and system include directories
While we want to enforce strict C90 mode, this may cause issues with
system provided header files which are themselves not strictly
conforming. E.g. if a system header has C++ style comments, a compiler
in strict C90 mode would produce an error and abort the build. As the
user most likely doesn't want to change the system header, this would
completely break the build on such systems. One example of this is
mbedtls, which provides such header files.
The problem can be worked around by distinguishing between
system-provided and project-provided include directories. When adding
include directories via "-isystem" instead of "-I", the compiler will
skip certain checks and print out less warnings. To use system includes,
we can simply add the "SYSTEM" flag to CMake's `INCLUDE_DIRECTORIES` and
`TARGET_INCLUDE_DIRECTORIES` functions. Note that we have to split the
include directories into two variables because of this, as we definitely
still want to check for all warnings produced by our own header files.
|
|
b89162af
|
2018-06-10T17:26:08
|
|
Link `mbedTLS` libraries in when `SHA1_BACKEND == "mbedTLS"`
|
|
90c6fb0f
|
2018-06-10T17:33:06
|
|
Fix typo in adding `hash_mbedtls.c` to `SRC_SHA1`
|
|
64a78a80
|
2018-05-25T09:28:52
|
|
mbedtls: don't require mbedtls from our pkgconfig file
mbedTLS has no pkgconfig file, hence we can't require it. For now, pass its link flags as our own.
|
|
8ab470f5
|
2018-04-27T15:31:43
|
|
cmake: remove now-useless LIBGIT2_LIBDIRS handling
With the recent change of always resolving pkg-config libraries to their
full path, we do not have to manage the LIBGIT2_LIBDIRS variable
anymore. The only other remaining user of LIBGIT2_LIBDIRS is winhttp,
which is a CMake-style library target and can thus be resolved by CMake
automatically.
Remove the variable to simplify our build system a bit.
|
|
0f62e4c7
|
2018-04-27T10:38:49
|
|
cmake: resolve libraries found by pkg-config
Libraries found by CMake modules are usually handled with their full
path. This makes linking against those libraries a lot more robust when
it comes to libraries in non-standard locations, as otherwise we might
mix up libraries from different locations when link directories are
given.
One excemption are libraries found by PKG_CHECK_MODULES. Instead of
returning libraries with their complete path, it will return the
variable names as well as a set of link directories. In case where
multiple sets of the same library are installed in different locations,
this can lead the compiler to link against the wrong libraries in the
end, when link directories of other dependencies are added.
To fix this shortcoming, we need to manually resolve library paths
returned by CMake against their respective library directories. This is
an easy task to do with `FIND_LIBRARY`.
|
|
54554757
|
2018-03-29T22:14:14
|
|
cmake: make our preferred backend ordering consistent
|
|
382ed1e8
|
2018-03-29T22:14:09
|
|
mbedtls: load default CA certificates
|
|
6c6be3ce
|
2018-03-29T22:13:59
|
|
mbedtls: use libmbedcrypto for hashing
|
|
ca3b2234
|
2018-03-29T22:13:56
|
|
mbedtls: initial support
|
|
b21c5408
|
2018-01-08T12:33:07
|
|
cmake: add openssl to the private deps list when it's the TLS implementation
We might want OpenSSL to be the implementation for SHA-1 and/or TLS. If we only
want it for TLS (e.g. we're building with the collision-detecting SHA-1
implementation) then we did not indicate this to the systems including us a
static library.
Add OpenSSL to the list also during the TLS decision to make sure we say we
should link to it if we use it for TLS.
|
|
b85548ed
|
2018-01-08T12:30:50
|
|
cmake: treat LIBGIT2_PC_REQUIRES as a list
It is indeed a list of dependencies for those which include the static archive.
This is in preparation for adding two possible places where we might add openssl
as a dependency.
|
|
70db57d4
|
2018-01-05T15:31:51
|
|
Merge pull request #4398 from pks-t/pks/generic-sha1
cmake: allow explicitly choosing SHA1 backend
|
|
70aa6146
|
2017-12-05T08:48:31
|
|
cmake: allow explicitly choosing SHA1 backend
Right now, if SHA1DC is disabled, the SHA1 backend is mostly chosen
based on which system libgit2 is being compiled on and which libraries
have been found. To give developers and distributions more choice,
enable them to request specific backends by passing in a
`-DSHA1_BACKEND=<BACKEND>` option instead. This completely replaces the
previous auto-selection.
|
|
30455a56
|
2018-01-03T13:09:21
|
|
Merge pull request #4439 from tiennou/fix/4352
cmake: create a dummy file for Xcode
|
|
4969a672
|
2017-12-10T02:19:34
|
|
cmake: create a dummy file for Xcode
Otherwise Xcode will happily not-link our git2 target, resulting in a "missing file" error when building eg. examples
|
|
bbb213c1
|
2017-11-11T13:19:24
|
|
cmake: let USE_ICONV be optional on macOS
Instead of forcing iconv support on macOS (by forcing `USE_ICONV`
on), honor the `USE_ICONV` option only on macOS.
Although macOS includes iconv by default, some macOS users may have a
deficient installation for some reason and they should be provided a
workaround to use libgit2 even in this situation.
iconv support is now disabled entirely on non-macOS platforms. No other
platform supports core.precomposeunicode, and iconv should never be
linked.
|
|
a0b0b808
|
2017-11-11T14:03:14
|
|
cmake: Allow user to select bundled zlib
Under some circumstances the installed / system version of zlib may not
be desirable due to being too old or buggy. This patch adds the option
`USE_BUNDLED_ZLIB` that will cause the bundled version of zlib to be
used.
We may also want to add similar functionality to allow the user to
select other bundled 3rd-party dependencies instead of using the system
versions.
/cc @pks-t @ethomson
|
|
c9bb68c2
|
2017-09-07T00:41:54
|
|
cmake: move Darwin-specific block around
This allows us to only link against CoreFoundation when using the SecureTransport backend
|
|
9980be03
|
2017-09-06T22:13:58
|
|
cmake: Add USE_HTTPS as a CMake option
It defaults to ON, e.g. "pick whatever default is appropriate for the platform".
It accepts one of SecureTransport, OpenSSL, WinHTTP, or OFF.
It errors if the backend library couldn't be found.
|