| Age | Commit message (Collapse) | Author |
|---|
|
The libgit2 `v1.1.0` is released two weeks ago. This PR allows `git2go` to link against the new version.
|
|
This change:
* Builds the library with Go 1.14, too.
* Builds the non-legacy tests with Ubuntu Focal (20.04).
* Adds testing for system-wide libraries, both static and dynamic
versions.
* Fixes a typo in the README.
|
|
This change allows to link the system version of libgit2 statically.
Since `-tags static` is already used for the bundled version of the
library and to avoid breaking old workflows, `-tags
static,system_libgit2` is now used to select that.
This means that the valid combinations are:
| Flag | Effect |
|-------------------------------|-----------------------------------------------|
| _No flags_ | Dynamically-linked against the system libgit2 |
| `-tags static,system_libgit2` | Statically-linked against the system libgit2 |
| `-tags static` | Statically-linked against the bundled libgit2 |
Note that there is no way to express dynamically linking against the
bundled libgit2 because that makes very little sense, since the binaries
wouldn't be able to be distributed. If that's still desired, the
`PKG_CONFIG_PATH` environment variable can set before building the code.
[`Makefile`](https://github.com/libgit2/git2go/blob/master/Makefile) has
an example of how it is used in the CI.
|
|
This change improves the documentation surrounding libgit2 static builds
and modules.
Fixes: #618
|
|
This uprevs libgit2 to the latest and greatest.
|
|
|
|
Clarifying the versions since we're using Go 1.11 module version rules now.
|
|
|
|
|
|
|
|
|
|
CGO can perform variable substitution in the directives, so we don't
need to use a script to set up the variables; we can let the go tool do
it for us.
|
|
|
|
|
|
|
|
|
|
The second mention still said that master tracks master. Add a mention
of next which will become the branch to track upstream tip.
|
|
With the release of libgit2 v0.22 we can link against a version of
library we've wrapped in more than a PoC sense.
Explain the difference and say how to use each version.
|
|
Add build status to README
|
|
|
|
|
|
To make sure it doesn't try to build it.
|
|
|
|
|
|
Specify that we stick to the release and how to run the tests.
|
|
|
|
This makes building the static version easier as we know where the repo
is and that it's has a known-good version.
|
|
|
|
|
|
|
