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.
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.
