Compiling libssh2 into libgit2 directly is madness. If users want to
create a single library that contains libssh2, then they should link a
static library.
For consistency, specify the nanosecond option in the same way as other
options, and identify it as such. Split the detection of platform
support (`FindStatNsec`) and its selection (`SelectNsec`).
The `USE_` prefix for inputs denotes a backend; the `DEBUG_` prefix
denotes a debugging option. Make `DEBUG_LEAK_CHECKER` the name of the
leak checking option.
Selecting regular expression backend should be specified in the same way
as everything else; `USE_REGEX`. Keep `REGEX_BACKEND` as an optional
fallback.
git's hash algorithm is sha1dc, it is not sha1. Per Linus:
> Honestly, git has effectively already moved from SHA1 to SHA1DC.
>
> So the actual known attack and weakness of SHA1 should simply not be
> part of the discussion for the next hash. You can basically say "we're
> _already_ on the second hash, we just picked one that was so
> compatible with SHA1 that nobody even really noticed.
Warn users who try to compile with SHA1 instead of SHA1DC.
Update the library's (API) version number to v1.9.0. Also update the
soname version number to 2.0, since we've had breaking ABI changes
to the library.
When `-DUSE_HTTP_PARSER=...` is specified, ensure that the specified
HTTP Parser is valid, do not fallback to builtin.
Restore `-DUSE_HTTP_PARSER=system` for backcompatibility.
Users can now set up cmake with -DC_STANDARD=... or -DC_EXTENSIONS=...
We default to C90 with C_EXTENSIONS=OFF, but callers can override if
they desire.
We may want to support SSH but with a different provider that is not
libssh2. Add GIT_SSH to indicate that we have some inbuilt SSH support
and GIT_SSH_LIBSSH2 to indicate that support is via libssh2. This is
similar to how we support GIT_HTTPS and GIT_OPENSSL, for example.
Provide a stream interface for Schannel - the native crypto APIs - on
Windows. This allows Windows to use the same HTTP transport that all the
other platforms use, with its own native crypto.
Ultimately this allows us to deprecate WinHTTP and we need not add
support for our socket changes in two places (our HTTP stack and the
WinHTTP stack).
xdiff is a dependency (from git core) and more properly belongs in the
'deps' directory. Move it there, and add a stub for cmake to resolve
xdiff from the system location in the future. (At present, bundled xdiff
remains hardcoded.)
libgit2 can be built with optional, experimental sha256 support. This
allows consumers to begin testing and providing feedback for our sha256
support while we continue to develop it, and allows us to make API
breaking changes while we iterate on a final sha256 implementation.
The results will be `git2-experimental.dll` and installed as
`git2-experimental.h` to avoid confusion with a production libgit2.
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.
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.
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.
Also applies to *_BINARY_DIR.
This effectively reverts 84083dcc8b,
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.
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.
