| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Nobody knows what CLAR is. The test building option should be
`BUILD_TESTS`.
|
|
|
| |
Add git24j to the language bindings
|
| |
|
| |
|
| |
|
|
|
| |
Delphi/Free pascal bindings targeting the latest version of libgit2
|
|
|
|
| |
[skip ci]
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
| |
Add instructions for building libgit2 in MinGW environment
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
As noted in docs/release.md, we only provide security updates for the
latest two releases. Let's thus drop the build status of both v0.27 and
v0.26 branches, adding the new v0.99 branch instead.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
GitHub has recently introduced a new set of tools that aims to
ease the process around vulnerability reports and security fixes.
Part of those tools is a new security tab for projects that will
display contents from a new SECURITY.md file.
Move relevant parts from README.md to this new file to make use
of this feature.
|
| |
|
|
|
|
|
| |
The URL was incorrect for the nightly badge image; it was erroneously
showing the master branch continuous integration build badge.
|
|
|
|
| |
Include a build badge for `maint/v0.28` builds.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
| |
Visual Studio Team Services is now a family of applications named "Azure
DevOps". Update the README to refer to it thusly.
|
|
|
|
|
| |
VSTS is now a family of components; "Azure Pipelines" is the build and
release pipeline application.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
We do not list all build options inside of the README.md, and we
definitly shouldn't do so. But in order to help people discover what can
be configured, add instructions on how to have CMake generate the list
of all knobs together with their current value.
|
|
|
|
|
| |
The syntax for links is `[description](link)z, not the other way round.
Fix this.
|
|
|
|
|
|
|
|
|
|
| |
Our non-technical documents are currently floating around loosely in our
project's root, making it harden than necessary to discover what one is
searching for. We do have a "docs/" directory, though, which serves
exactly that purpose of hosting documentation.
Move our non-technical documentation into the "docs/" directory. Adjust
all links to these documents.
|
|
|
|
|
|
|
| |
By now, our README has grown quite long, and at multiple occassions
people were unable to find the correct spot in our documentation. Add a
table of contents to at least present an overview over all topics that
are being covered by our README.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Since we recommend `ctest -V`, it's not clear why somebody would want to
run `libgit2_clar`. Indicate that it's helpful when running individual
tests or suites.
|
|
|
|
|
| |
Provide a very simple quick start paragraph that highlights how easy it
is to get started, and points people toward common problems.
|
|
|
|
|
| |
Users should not be advised to use the VS command prompt; instead, they
should let cmake find their Visual Studio installation.
|
|
|
|
|
|
|
|
|
|
| |
Suggest that users run `ctest -V` instead of `make test` when getting
started. `ctest -V` is superior over alternatives as:
1. Unlike `make test`, it gives output. Users getting started with
the library believe that it is hung.
2. `ctest -V` shows verbose output; showing suite names is helpful for
giving users more feedback immediately.
|
| |
|
|
|
|
|
| |
libgit2 is no longer used in Visual Studio Team Services, it's used in
Visual Studio Team Services.
|
|
|
|
|
|
| |
libgit2 is a mere consumer of changes which are trickling down from the
upstream git.git project. This commit documents the ramifications caused
by this relation.
|
| |
|
|\
| |
| | |
README: be more explicit in the goals and scope
|
| |
| |
| |
| |
| | |
Make it clearer from the get-go that we do not aim to implement
user-facing commands from the git tool.
|