|
b900981c
|
2021-12-12T14:25:25
|
|
sha: add sha256 algorithm
Add support for a SHA256 hash algorithm, and add the "builtin" SHA256
hash engine (from RFC 6234).
|
|
8bc998f4
|
2021-12-12T12:44:13
|
|
sha1: remove generic implementation
Remove the "generic" implementation; it should never be used; it only
existed for a no-dependencies configuration, and our bundled sha1dc
satisfies that requirement _and_ is correct.
|
|
b08fe71d
|
2022-02-27T23:16:05
|
|
cmake: export libraries needed to compile against libgit2
If users are using us as a direct dependency (via `add_subdirectory`)
then they may want to know the libraries to link to; tell them.
|
|
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.
|
|
5fcfada5
|
2021-11-15T07:45:16
|
|
cmake: document CMakeLists.txt hierarchy
|
|
ae74d5ac
|
2022-02-14T07:01:43
|
|
meta: update version number to v1.5.0-alpha
Update the version number in main to v1.5.0-alpha. This helps people
understand that the main builds are not part of the v1.4.0 release
train.
We use "alpha" to indicate builds out of main (or nightlies) as semver
v2 requires the prerelease component is compared lexicographically.
Thus, our "beta" and "rc" releases should follow.
|
|
5c949d1f
|
2022-02-13T10:06:15
|
|
v1.4: update version numbers
|
|
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`.
|
|
4a54d8e3
|
2021-11-17T07:27:39
|
|
cmake: enable testing at the top level
Ensure that we `enable_testing()` at the top-level CMakeLists.txt or
else we'll need to navigate within the build directory to the correct
place in the hierarchy to run `ctest`. Now we can `ctest` at the
top-level again.
|
|
c7f6ecb3
|
2021-11-11T22:54:14
|
|
cmake: use a string not a boolean for LIBGIT2_FILENAME
|
|
d3a7a352
|
2021-11-06T16:44:07
|
|
cmake: move test enablement into test cmake
|
|
207beff5
|
2021-11-06T16:43:04
|
|
cmake: reorganize file
|
|
4d2a6839
|
2021-11-06T16:38:57
|
|
cmake: move fuzzer args to the fuzzer's cmake
|
|
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.
|
|
9f37457e
|
2021-11-06T16:23:03
|
|
cmake: move cflag defaults into a separate module
|
|
6c00fcb7
|
2021-11-10T17:32:41
|
|
cmake: USE_SSH is not on by default
|
|
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.
|
|
e1be28c7
|
2021-09-26T22:02:04
|
|
cmake: remove unused STDCALL option
The `STDCALL` option was removed; remove the (unreachable) error
message.
|
|
8507bf81
|
2021-09-26T21:54:08
|
|
trace: always enabled
There's no need to make tracing opt-in; it should always be included.
|
|
780faa41
|
2021-09-26T21:51:16
|
|
cmake: allow USE_ICONV on any Unix
|
|
7f5b0f0c
|
2021-09-26T21:50:19
|
|
cmake: allow ENABLE_REPRODUCIBLE_BUILDS on macOS
macOS may support ENABLE_REPRODUCIBLE_BUILDS, allow users to opt-in to
it. (Especially since ENABLE_REPRODUCIBLE_BUILDS is not the default.)
|
|
4e14d4c6
|
2021-09-26T22:06:49
|
|
cmake: BUILD_CLAR is now BUILD_TESTS
Nobody knows what CLAR is. The test building option should be
`BUILD_TESTS`.
|
|
e7437162
|
2021-09-22T08:35:02
|
|
v1.3: update version number
|
|
c811fc36
|
2021-08-31T00:13:42
|
|
v1.2: update version information
|
|
c7a195a1
|
2021-08-25T14:11:03
|
|
Merge pull request #6006 from boretrk/c11-warnings
GCC C11 warnings
|
|
0850b172
|
2021-08-25T12:20:50
|
|
Merge pull request #5950 from boretrk/posixtest
open: input validation for empty segments in path
|
|
b0189582
|
2021-08-25T18:07:01
|
|
enable gcc warnings for C11 specific extensions
|
|
51d69dda
|
2021-08-25T11:34:59
|
|
enable warnings for C11 specific extensions
|
|
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)
```
|
|
8aed4629
|
2020-07-12T18:43:22
|
|
cmake: rename MSVC_CRTDBG to WIN32_LEAKCHECK
|
|
f10c8875
|
2020-10-11T23:04:08
|
|
Release v1.1
|
|
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.
|
|
511fb9e6
|
2020-04-03T22:53:23
|
|
cmake: always disable deprecation-sync warnings
We currently disable deprecation synchronization warnings in case we're
building with Clang. We check for Clang by doing a string comparison on
the compiler identification, but this seems to have been broken by an
update in macOS' image as the compiler ID has changed to "AppleClang".
Let's just unconditionally disable this warning on Unix platforms. We
never add the deprecated attribute anyway, so the warning doesn't help
us at all.
|
|
3956679c
|
2020-04-03T20:08:02
|
|
cmake: remove policies
The `CMAKE_MINIUM_REQUIRE()` function not only sets up the minimum
required CMake version of a project, but it will also at the same time
set the CMake policy version. In effect this means that all policies
that have been introduced before the minimum CMake version will be
enabled automatically.
When updating our minimum required version ebabb88f2 (cmake: update
minimum CMake version to v3.5.1, 2019-10-10), we didn't remove any of
the policies we've been manually enabling. The newest CMake policy we've
been enabling is CMP0054, which was introduced back in CMake v3.1. As a
result, we can now just remove all manual calls to `CMAKE_POLICY()`.
|
|
2e7d4579
|
2020-04-03T19:59:39
|
|
cmake: remove option to add profiling flags
We currently have an option that adds options for profiling to both our
CFLAGS and LDFLAGS. Having such flags behind various build options is
not really sensible at all, since users should instead set up those
flags via environment variables supported by CMake itself.
Let's remove this option.
|
|
2551b1b0
|
2020-04-03T19:53:35
|
|
cmake: remove support for creating tags
We currently have support for generating tags via ctags as part of our
build system. We aren't really in the place of supporting any tooling
that exists apart from the actual build environment, as doing so adds
additional complexity and maintenance burden to our build instructions.
This is in fact nicely demonstrated by this particular option, as it
hasn't been working anymore since commit e5c9723d0 (cmake: move library
build instructions into subdirectory, 2017-06-30).
As a result, this commit removes support for building CTags
|
|
bc02bcd9
|
2020-04-03T19:51:22
|
|
cmake: move modules into the "cmake/" top level dir
Our custom CMake module currently live in "cmake/Modules". As the
"cmake/" directory doesn't contain anything except the "Modules"
directory, it doesn't really make sense to have the additional
intermediate directory. So let's instead move the modules one level up
into the "cmake/" top level directory.
|
|
63f9fbee
|
2020-04-25T15:37:45
|
|
MSVC: Enable Control Flow Guard (CFG)
This feature requires Visual Studio 2015 (MSVC_VERSION = 1900) or later. As the
minimum required CMake version is currently less than 3.7, GREATER_EQUAL is not
available to us and we must invert the result of the LESS operator.
|
|
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.
|
|
70062e28
|
2019-10-31T17:46:21
|
|
version: update the version number to v0.99
This commit also switches our SOVERSION to be "$MAJOR.$MINOR" instead of
"$MINOR", only. This is in preparation of v1.0, where the previous
scheme would've stopped working in an obvious way.
|
|
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.
|
|
625a3a49
|
2019-11-27T12:29:34
|
|
trace: enable tracing by default
Tracing is meant to be extremely low-impact when not enabled. We
currently ship no tracing calls in libgit2, but if / when we do, the
tracing infrastructure is created to skip tracing as quickly as
possible. It should compile to a simple test when tracing is off.
Thus, there's on reason to not enable it by default.
|
|
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
|
|
071750a3
|
2019-08-15T14:18:26
|
|
cmake: move _WIN32_WINNT definitions to root
|
|
d827b11b
|
2019-06-28T13:20:54
|
|
tests: execute leak checker via CTest directly
Right now, we have an awful hack in our test CI setup that extracts the
test command from CTest's output and then prepends the leak checker.
This is dependent on non-machine-parseable output from CMake and also
breaks on various ocassions, like for example when we have spaces in the
current path or when the path contains backslashes. Both conditions may
easily be triggered on Win32 systems, and in fact they do break our
Azure Pipelines builds.
Remove the awful hack in favour of a new CMake build option
"USE_LEAK_CHECKER". If specifying e.g. "-DUSE_LEAK_CHECKER=valgrind",
then we will set up all tests to be run under valgrind. Like this, we
can again simply execute ctest without needing to rely on evil sourcery.
|
|
e61b92e0
|
2019-06-24T15:22:39
|
|
clang: disable documentation-deprecated-sync
Add the `-Wno-documentation-deprecated-sync` switch when compiling with
clang, since our documentation adds `deprecated` markers, but we do not
add the deprecation attribute in the code itself. (ie, the code is out
of sync with the docs).
In fact, we do not _want_ to mark these items as deprecated in the code,
at least not yet, as we are not quite ready to bother our end-users with
this since they're not going away.
|
|
54a60ced
|
2019-06-15T21:45:26
|
|
mingw: disable format specification warnings
MinGW uses gcc, which expects POSIX formatting for printf, but uses the
Windows C library, which uses its own format specifiers. Therefore, it
gets confused about format specifiers. Disable warnings for format
specifiers.
|
|
393fb8a1
|
2019-06-17T12:15:19
|
|
cmake: default NTLM client to off if no HTTPS support
If building libgit2 with `-DUSE_HTTPS=NO`, then CMake will
generate an error complaining that there's no usable HTTPS
backend for NTLM. In fact, it doesn't make sense to support NTLM
when we don't support HTTPS. So let's should just have
NTLM default to OFF when HTTPS is disabled to make life easier
and to fix our OSSFuzz builds failing.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
dcf81cdb
|
2019-02-13T23:56:40
|
|
deprecation: optionally enable hard deprecation
Add a CMake option to enable hard deprecation; the resultant library
will _not_ include any deprecated functions. This may be useful for
internal CI builds that create libraries that are not shared with
end-users to ensure that we do not use deprecated bits internally.
|
|
24ac9e0c
|
2019-02-13T23:26:54
|
|
deprecation: ensure we GIT_EXTERN deprecated funcs
Although the error functions were deprecated, we did not properly mark
them as deprecated. We need to include the `deprecated.h` file in order
to ensure that the functions get their export attributes.
Similarly, do not define `GIT_DEPRECATE_HARD` within the library, or
those functions will also not get their export attributes. Define that
only on the tests and examples.
|
|
7ed2baf7
|
2019-01-21T00:41:50
|
|
MSVC: ignore empty compilation units (warning LNK4221)
A number of source files have their implementation #ifdef'd out (because
they target another platform). MSVC warns on empty compilation units
(with warning LNK4221). Ignore warning 4221 when creating the object
library.
|
|
c951b825
|
2019-01-23T00:32:40
|
|
deprecation: define GIT_DEPRECATE_HARD internally
Ensure that we do not use any deprecated functions in the library
source, test code or examples.
|
|
57b753a0
|
2019-01-09T12:47:40
|
|
cmake: error when STDCALL is specified
To explicitly break end-users who were specifying STDCALL, explicitly
fail the cmake process to ensure that they know that they need to change
their bindings. Otherwise, we would quietly ignore their option and the
resulting cdecl library would produced undefined behavior.
|
|
a74dd39b
|
2019-01-09T12:33:47
|
|
Use cdecl calling conventions on Win32
The recommendation from engineers within Microsoft is that libraries
should have a calling convention specified in the public API, and that
calling convention should be cdecl unless there are strong reasons to
use a different calling convention.
We previously offered end-users the choice between cdecl and stdcall
calling conventions. We did this for presumed wider compatibility: most
Windows applications will use cdecl, but C# and PInvoke default to
stdcall for WINAPI compatibility. (On Windows, the standard library
functions are are stdcall so PInvoke also defaults to stdcall.)
However, C# and PInvoke can easily call cdecl APIs by specifying an
annotation.
Thus, we will explicitly declare ourselves cdecl and remove the option
to build as stdcall.
|
|
2cc66dd5
|
2019-01-10T17:03:38
|
|
cmake: remove unconditional -Wno-deprecated-declaration on APPLE
After taking into consideration the following, I think this should be
removed :
- OpenSSL isn't the default on Apple platforms
- you have to jump through hoops to get CMake to use OpenSSL on macOS
(headers aren't in `/usr/include`, so you have to provide `-DOPENSSL_*`
overrides)
- users are likely (as getting anywhere near the installed 0.9.8 version
is insanity IMHO) to package a "modern" version, which wouldn't be
marked as deprecated
|
|
487233fa
|
2018-11-29T07:21:41
|
|
Merge pull request #4895 from pks-t/pks/unused-warnings
Unused function warnings
|
|
3a2e4836
|
2018-11-18T09:52:12
|
|
CMake: disable deprecated documentation sync
The `-Wdocumentation-deprecated-sync` option will warn when there is a
doxygen `\deprecated` tag but there is no corresponding deprecation
attribute on the function. We want to encourage users to not use
particular APIs by marking them deprecated in the documentation without
necessarily raising a compiler warning by marking an item as deprecated.
|
|
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.
|
|
ffe39bab
|
2018-11-23T20:04:37
|
|
cmake: enable warnings for unused const variables
Together with the warnings for unused warnings, we always had warnings
for unused constant variables disabled since commit 823c0e9cc (Fix
broken logic for attr cache invalidation, 2014-04-17). As we have now
fixed all occurrences of such variables, we can safely enable those
warnings again.
|
|
681c58cf
|
2018-11-21T11:21:02
|
|
cmake: enable warnings for unused functions
Ever since commit 823c0e9cc (Fix broken logic for attr cache invalidation,
2014-04-17), we have completely disabled warnings for unused functions. The only
comment that was added back then is about "annoying extra warnings" from Clang,
but in fact we shouldn't just ignore warnings about functions which aren't used
at all. Instead, the right thing would be to either only conditionally compile
functions that aren't used in all configurations or, alternatively, to remove
functions that aren't required at all.
As remaining instances of unused functions have been removed in the last two
commits, re-enable the warning.
|
|
b160a64f
|
2018-10-17T09:38:30
|
|
cmake: correct comment from libssh to libssh2
We use libssh2. We do not use libssh. Make sure to disambiguate them
correctly.
|
|
aa0ae59a
|
2018-10-05T10:31:53
|
|
cmake: explicitly enable int-conversion warnings
While GCC enables int-conversion warnings by default, it will currently
only warn about such errors even in case where "-DENABLE_WERROR=ON" has
been passed to CMake. Explicitly enable int-conversion warnings by using
our `ENABLE_WARNINGS` macro, which will automatically use
"-Werror=int-conversions" in case it has been requested by the user.
|
|
633584b5
|
2018-10-04T10:48:12
|
|
cmake: enable new quoted argument policy CMP0054
Quoting from CMP0054's documentation:
Only interpret if() arguments as variables or keywords when
unquoted.
CMake 3.1 and above no longer implicitly dereference variables or
interpret keywords in an if() command argument when it is a Quoted
Argument or a Bracket Argument.
The OLD behavior for this policy is to dereference variables and
interpret keywords even if they are quoted or bracketed. The NEW
behavior is to not dereference variables or interpret keywords that
have been quoted or bracketed.
The previous behaviour could be quite unexpected. Quoted arguments might
be expanded in case where the value of the argument corresponds to a
variable. E.g. `IF("MONKEY" STREQUAL "MONKEY")` would have been expanded
to `IF("1" STREQUAL "1")` iff `SET(MONKEY 1)` was set. This behaviour
was weird, and recent CMake versions have started to complain about this
if they see ambiguous situations. Thus we want to disable it in favor of
the new behaviour.
|
|
04d3853f
|
2018-10-04T10:47:29
|
|
cmake: remove spaces between `IF` and `(` for policies
Our CMake coding style dictates that there should be no space between
`IF` and its opening `(`. Adjust our policy statements to honor this
style.
|
|
1621a37d
|
2018-09-29T13:22:59
|
|
Merge pull request #4812 from libgit2/ethomson/ci-refactor
CI: refactoring
|
|
f2c1153d
|
2018-09-17T20:38:05
|
|
cmake: enable -Wformat and -Wformat-security
We do not currently have any warnings in this regard, but it's good practice to
have them on in case we introduce something.
|
|
943181c2
|
2018-09-10T12:36:51
|
|
Revert "clar: introduce CLAR_XML option"
This reverts commit a2d73f5643814cddf90d5bf489332e14ada89ab8.
Using clar to propagate the XML settings was a mistake.
|
|
a2d73f56
|
2018-08-24T11:23:19
|
|
clar: introduce CLAR_XML option
Introduce a CLAR_XML option, to run the `ctest` commands with the new
`-r` flag to clar. Permitted values are `OFF`, `ON` and a directory to
write the XML test results to.
|
|
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.
|
|
12804c46
|
2018-07-20T12:24:08
|
|
cmake: remove USE_SANITIZER and USE_COVERAGE options
Both the USE_SANITIZER and USE_COVERAGE options are convenience options
that turn on a set of CFLAGS. Despite our own set of CFLAGS required to
build libgit2, we have no real business to mess with them, though, as
they can easily be passed in by the user via specifying the CFLAGS
environment variable. The reasoning behind not providing them is that as
soon as we start adding those for some usecases, users might ask for
other sets of CFLAGS catering to their specific need in another usecase.
Thus, we do not want to support them here.
|
|
ad0cb297
|
2018-07-20T12:17:42
|
|
cmake: fix the unholy options alignment mess
|
|
186a7ba5
|
2018-07-19T15:13:40
|
|
cmake: error out if required C flags are not supported
We do want to notify users compiling our source code early on if they
try to use C flags which aren't supported. Add a new macro `AddCFlag`,
which results in a fatal error in case the flag is not supported, and
use it for our fuzzing flags.
|
|
59328ed8
|
2018-07-19T13:29:46
|
|
fuzzers: rename "fuzz" directory to match our style
Our layout uses names like "examples" or "tests" which is why the "fuzz"
directory doesn't really fit in here. Rename the directory to be called
"fuzzers" instead. Furthermore, we rename the fuzzer "fuzz_packfile_raw"
to "packfile_raw_fuzzer", which is also in line with the already
existing fuzzer at google/oss-fuzz.
While at it, rename the "packfile_raw" fuzzer to instead just be called
"packfile" fuzzer.
|
|
60e610a2
|
2018-01-04T15:36:22
|
|
fuzzers: add build support and instructions
This change adds support for building a fuzz target for exercising the
packfile parser, as well as documentation. It also runs the fuzzers in
Travis to avoid regressions.
|
|
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.
|
|
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`.
|
|
6c6be3ce
|
2018-03-29T22:13:59
|
|
mbedtls: use libmbedcrypto for hashing
|
|
e666495b
|
2018-03-08T08:31:49
|
|
cmake: enable shift count overflow warning
|
|
522f3e4b
|
2018-02-16T10:50:54
|
|
CMakeLists: increase strict aliasing level to 3
The strict aliasing rules disallow dereferencing the pointer to a
variable of a certain type as another type, which is frequently used
e.g. when casting structs to their base type. We currently have the
warning level for strict aliasing rules set to `2`, which is described
by gcc(1) as being "Aggressive, quick, not too precise." And in fact, we
experience quite a lot of warnings when doing a release build due to
that.
GCC provides multiple levels, where higher levels are more accurate, but
also slower due to the additional analysis required. Still, we want to
have warning level 3 instead of 2 to avoid the current warnings we have
in the Travis CI release builds. As this is the default warning level
when no level is passed to `-Wstrict-aliasing`, we can just remove the
level and use that default.
|
|
f8a2dda8
|
2018-02-05T15:21:37
|
|
cmake: move ENABLE_WARNINGS to a module
|
|
fc6e38c2
|
2018-02-02T18:03:38
|
|
cmake: Move IDE source munging to a module
Move the odd code that provides a hierarchical display for projects
within the IDEs to its own module.
|
|
ed298c8e
|
2018-02-02T18:01:51
|
|
cmake: move nanosecond detection to a module
Move the nanosecond detection in time structures to its own module.
|
|
6416b91f
|
2018-02-02T17:58:44
|
|
cmake: enable policy CMP0042
Enable CMake policy CMP0042, if supported:
> CMake 2.8.12 and newer has support for using ``@rpath`` in a target's
> install name. This was enabled by setting the target property
> ``MACOSX_RPATH``. The ``@rpath`` in an install name is a more
> flexible and powerful mechanism than ``@executable_path`` or
> ``@loader_path`` for locating shared libraries.
|
|
94aa36ef
|
2018-02-02T17:56:15
|
|
cmake: test for CMP0051 instead of version check
We can use policy checks to see if a policy exists in cmake, like
CMP0051, instead of relying on the version.
|
|
6d452600
|
2018-01-10T11:52:15
|
|
cmake: use a FEATURE_SUMMARY call compatible with 3.0.2
When we print features, we make an effort to support all the way back to
pre-3.0. However, in the code for versions from 3 onward we call
`FEATURE_SUMMARY` with multiple kinds of elements to print in the same line.
This is only supported in CMake 3.1 and later, making the rather popular CMake
3.0.2 unable to build the library.
Use a single kind of element per invocation. This means we need to provide a
"description" text, which CMake provides for us if provide multiple kinds of
elements.
|
|
ddd36510
|
2018-01-07T15:40:06
|
|
Merge pull request #4467 from libgit2/cmn/static-archive-later
cmake: move the rule to find static archives close to building clar
|
|
85e40bbf
|
2018-01-07T12:51:26
|
|
cmake: move the rule to find static archives close to building clar
If we're building static libraries, we want to use that for building our clar
binary. This is done in 49551254 (2017-09-22; cmake: use static dependencies
when building static libgit2) but that commit included the rule too early,
making it affect the search for iconv, meaning we did not find it when we were
building a static libgit2.
Move the rule to just before building clar, after we've included the rules for
building the library itself. This lets us find and link to the dynamic libiconv.
|