|
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.
|
|
|
70aa6146
|
2017-12-05T08:48:31
|
|
cmake: allow explicitly choosing SHA1 backend
Right now, if SHA1DC is disabled, the SHA1 backend is mostly chosen
based on which system libgit2 is being compiled on and which libraries
have been found. To give developers and distributions more choice,
enable them to request specific backends by passing in a
`-DSHA1_BACKEND=<BACKEND>` option instead. This completely replaces the
previous auto-selection.
|
|
|
e7495ce6
|
2017-12-05T08:47:57
|
|
cmake: default to using SHA1DC
Upstream git.git has changed their default SHA1 implementation to the
collision-detection algorithm SHA1DC in commit e6b07da27 (Makefile: make
DC_SHA1 the default, 2017-03-17). To match upstream, align ourselves and
switch over to SHA1DC by default.
|
|
|
bbb213c1
|
2017-11-11T13:19:24
|
|
cmake: let USE_ICONV be optional on macOS
Instead of forcing iconv support on macOS (by forcing `USE_ICONV`
on), honor the `USE_ICONV` option only on macOS.
Although macOS includes iconv by default, some macOS users may have a
deficient installation for some reason and they should be provided a
workaround to use libgit2 even in this situation.
iconv support is now disabled entirely on non-macOS platforms. No other
platform supports core.precomposeunicode, and iconv should never be
linked.
|
|
a0b0b808
|
2017-11-11T14:03:14
|
|
cmake: Allow user to select bundled zlib
Under some circumstances the installed / system version of zlib may not
be desirable due to being too old or buggy. This patch adds the option
`USE_BUNDLED_ZLIB` that will cause the bundled version of zlib to be
used.
We may also want to add similar functionality to allow the user to
select other bundled 3rd-party dependencies instead of using the system
versions.
/cc @pks-t @ethomson
|
|
|
c9bb68c2
|
2017-09-07T00:41:54
|
|
cmake: move Darwin-specific block around
This allows us to only link against CoreFoundation when using the SecureTransport backend
|
|
|
9980be03
|
2017-09-06T22:13:58
|
|
cmake: Add USE_HTTPS as a CMake option
It defaults to ON, e.g. "pick whatever default is appropriate for the platform".
It accepts one of SecureTransport, OpenSSL, WinHTTP, or OFF.
It errors if the backend library couldn't be found.
|
|
|
10b25dbf
|
2017-08-10T00:03:30
|
|
cmake: braces are not needed here
|
|
|
fdd06874
|
2017-08-09T21:35:53
|
|
cmake: use FeatureSummary to display which features we end up using
|
|
|
4da74c83
|
2017-10-20T07:29:17
|
|
cmake: use project-relative binary and source directories
Due to our split of CMake files into multiple modules, we had to replace
some uses of the `${CMAKE_CURRENT_SOURCE_DIR}` and
`${CMAKE_CURRENT_BINARY_DIR}` variables and replace them with
`${CMAKE_SOURCE_DIR}` and `${CMAKE_BINARY_DIR}`. This enabled us to
still be able to refer to top-level files when defining build
instructions inside of a subdirectory.
When replacing all variables, it was assumed that the absolute set of
variables is always relative to the current project. But in fact, this
is not the case, as these variables always point to the source and
binary directory as given by the top-levl project. So the change
actually broke the ability to include libgit2 directly as a subproject,
as source files cannot be found anymore.
Fix this by instead using project-specific source and binary directories
with `${libgit2_SOURCE_DIR}` and `${libgit2_BINARY_DIR}`.
|
|
8bbee8f3
|
2017-10-14T08:36:54
|
|
Fix compilation for CMake versions 3.0.x where x >= 1
Apparently policy CMP0015 was added in CMake 3.1. With CMake 3.0.2,
the build was failing with
CMake Error at CMakeLists.txt:18 (CMAKE_POLICY):
Policy "CMP0051" is not known to this version of CMake.
This patch makes it work.
|
|
|
8ac8c78c
|
2017-10-09T15:15:08
|
|
Merge pull request #4356 from pks-t/pks/static-clar
cmake: use static dependencies when building static libgit2
|
|
|
49551254
|
2017-09-22T09:34:37
|
|
cmake: use static dependencies when building static libgit2
CMake allows us to build a static library by simply setting the variable
`BUILD_SHARED_LIBS` to `OFF`. While this causes us to create a static
libgit2.a archive, it will not automatically cause CMake to only locate
static archives when searching for dependencies. This does no harm in
case of building our libgit2.a, as we do not want to include all
required dependencies in the resulting archive anyway. Instead, we ask
users of a static libgit2.a to link against the required set of static
archives themselves, typically aided by the libgit2.pc file.
Where it does cause harm, though, is when we build the libgit2_clar test
suite. CMake has happily populated our LIBGIT2_LIBS variable with shared
libraries, and so linking the final libgit2_clar test does not do the
right thing. It will simply ignore those shared libraries, we end up
with a test suite with undefined symbols.
To fix the issue, we can instruct CMake to only locate libraries with a
certain suffix. As static libraries are typically identifiable by their
".a" suffix on Unix-based systems, we can instruct CMake to only locate
libraries with this suffix to restrict it from finding any shared
libraries. This fixes building a static libgit2_clar test suite.
Note that this ignores the problem on Windows. The problem here is that
we cannot even distinguish static and dynamic libraries by only
inspecting their suffix. So we just ignore the problem on Windows, for
now.
|
|
|
cf9f3452
|
2017-09-06T07:38:32
|
|
cmake: bump minimum version to 2.8.11
Our current minimum CMake version is 2.8. This version does not yet
allow us to use object libraries (introduced in 2.8.8) and target
include directories (introduced in 2.8.12), which are both mechanisms we
want to use to fix some specific problems. We previously were not able
to bump our CMake version to a version supporting object libraries
because Ubuntu Precise only had CMake version 2.8.7 in its repositories.
But due to Precise being end of life now, we shouldn't need to honor it
anymore. A current survey of some of the more conservative distributions
brings up the following versions of CMake:
- CentOS 5: 2.6.2
- CentOS 6: 2.8.12.2
- Debian 7: 2.8.11
- Fedora 23: 3.3.2
- OpenSUSE 13.2: 3.0.2
- Ubuntu Precise: 2.8.7
- Ubuntu Trusty: 2.8.12
The only two outliers here are CentOS 5 and Ubuntu Precise. CentOS is
currently unsupported due to our minimum version being 2.8 and Ubuntu
Precise is not maintained anymore. So the next smallest version
supported by all major distributions is 2.8.11. While this does not yet
support target include directories, it at least enables us to use object
libraries. So this becomes our new minimum required version.
|
|
|
524c1d3c
|
2017-09-20T07:48:19
|
|
Merge pull request #4334 from pks-t/pks/reproducible-builds
Reproducible builds
|
|
|
54214d61
|
2017-09-15T10:28:32
|
|
cmake: fix linker error with dbghelper library
When the MSVC_CRTDBG option is set by the developer, we will link in the
dbghelper library to enable memory lead detection in MSVC projects. We
are doing so by adding it to the variable `CMAKE_C_STANDARD_LIBRARIES`,
so that it is linked for every library and executable built by CMake.
But this causes our builds to fail with a linker error:
```
LINK: fatal error LNK1104: cannot open file 'advapi32.lib;Dbghelp.lib'
```
The issue here is that we are treating the variable as if it were an
array of libraries by setting it via the following command:
```
SET(CMAKE_C_STANDARD_LIBRARIES "${CMAKE_C_STANDARD_LIBRARIES}"
"Dbghelp.lib")
```
The generated build commands will then simply stringify the variable,
concatenating all the contained libraries with a ";". This causes the
observed linking failure.
To fix the issue, we should just treat the variabable as a simple
string. So instead of adding multiple members, we just add the
"Dbghelp.lib" library to the existing string, separated by a space
character.
|
|
|
d630887b
|
2017-08-30T21:47:12
|
|
cmake: enable reproducible static linking
By default, both ar(1) and ranlib(1) will insert additional information
like timestamps into generated static archives and indices. As a
consequence, generated static archives are not deterministic when
created with default parameters.
Both programs do support a deterministic mode, which will simply zero
out undeterministic information with `ar D` and `ranlib -D`.
Unfortunately, CMake does not provide an easy knob to add these command
line parameters. Instead, we have to redefine the complete command
definitons stored in the variables CMAKE_C_ARCHIVE_CREATE,
CMAKE_C_ARCHIVE_APPEND and CMAKE_C_ARCHIVE_FINISH.
Introduce a new build option `ENABLE_REPRODUCIBLE_BUILDS`. This option
is available on Unix-like systems with the exception of macOS, which
does not have support for the required flags. If the option is being
enabled, we add those flags to the invocation of both `ar` and `ranlib`
to enable deterministically building the static archive.
|
|
|
175ab8e7
|
2017-08-25T17:36:24
|
|
cmake: add switch to build with -Werror
Add a simple switch to enable building with "-Werror=<warning>" instead
of "-W<warning". Due to the encapsulated `ENABLE_WARNINGS` macro, this
is as simple as adding a new variable "ENABLE_WERROR`, which can be
passed on the command line via `-DENABLE_WERROR=ON`. The variable
defaults to NO to not bother developers in their day to day work.
|
|
|
4a46a8c1
|
2017-08-25T17:32:54
|
|
cmake: encapsulate enabling/disabling compiler warnings
There are multiple sites where we enable or disable compiler warning via
"-W<warning>" or "-Wno-<warning>". As we want to extend this mechanism
later on to conditionally switch these over to "-Werror=<warning>", we
encapsulate the logic into its their own macros `ENABLE_WARNINGS` and
`DISABLE_WARNINGS`.
Note that we in fact have to use a macro here. Using a function would
not modify the CFLAGS inside of the callers scope, but in the function's
scope only.
|
|
|
e5c9723d
|
2017-06-30T18:12:02
|
|
cmake: move library build instructions into subdirectory
To fix leaking build instructions into different targets and to make
the build instructions easier to handle, create a new CMakeLists.txt
file containing build instructions for the libgit2 target.
By now, the split is rather easy to achieve. Due to the preparatory
steps, we can now simply move over all related build instructions, only
needing to remove the "src/" prefix from some files.
|
|
|
72f27cb6
|
2017-06-30T17:02:00
|
|
cmake: fix up source and binary directory paths
There are quite some uses of the variables "${CMAKE_CURRENT_SOURCE_DIR}"
and "${CMAKE_CURRENT_BINARY_DIR}" where they are not appropriate.
Convert these sites to instead use the variables "${CMAKE_SOURCE_DIR}"
and "${CMAKE_BINARY_DIR}", which instead point to the project's root
directory.
This will ease splitting up the library build instructions into its own
subdirectory.
|
|
|
1f43a43d
|
2017-06-28T13:28:33
|
|
cmake: move zlib build instructions into subdirectory
Extract code required to build the zlib library into its own
CMakeLists.txt, which is included as required.
|
|
|
b7514554
|
2017-06-28T13:25:09
|
|
cmake: move http-parser build instructions into subdirectory
Extract code required to build the http-parser library into its own
CMakeLists.txt, which is included as required.
|
|
|
9e449e52
|
2017-06-28T13:23:45
|
|
cmake: move regex build instructions into subdirectory
Extract code required to build the regex library into its own
CMakeLists.txt, which is included as required.
|
|
|
43248500
|
2017-06-28T13:21:09
|
|
cmake: move winhttp build instructions into subdirectory
Extract code required to build the winhttp library into its own
CMakeLists.txt, which is included as required.
|
|
|
bed7ca3a
|
2017-06-30T16:57:16
|
|
cmake: define WIN_RC with other platform sources
This makes splitting up the library build instructions later on more
obvious and easier to achieve.
|
|
|
8ee90c39
|
2017-06-28T13:16:38
|
|
cmake: find dependencies after setting build flags
This makes splitting up the library build instructions later on more
obvious and easier to achieve.
|
|
|
c3635130
|
2017-06-28T13:14:23
|
|
cmake: move definition of Win32 flags together
This makes splitting up the library build instructions later on more
obvious and easier to achieve.
|
|
|
32a2e500
|
2017-07-01T13:41:36
|
|
cmake: inline TARGET_OS_LIBRARIES function
Previous to keeping track of libraries and linking directories via
variables, we had two call sites of the `TARGET_OS_LIBRARIES` function
to avoid duplicating knowledge on required operating system library
dependencies. But as the libgit2_clar target now re-uses defined
variables to link against these libraries, we can simply inline the
function.
|
|
|
8e31cc25
|
2017-06-28T12:51:14
|
|
cmake: keep track of libraries and includes via lists
Later on, we will move detection of required libraries, library
directories as well as include directories into a separate
CMakeLists.txt file inside of the source directory. Obviously, we want
to avoid duplication here regarding these parameters.
To prepare for the split, put the parameters into three variables
LIBGIT2_LIBS, LIBGIT2_LIBDIRS and LIBGIT2_INCLUDES, tracking the
required libraries, linking directory as well as include directories.
These variables can later be exported into the parent scope from inside
of the source build instructions, making them readily available for the
other subdirectories.
|
|
|
dd332e2a
|
2017-06-23T20:42:41
|
|
cmake: use absolute path to deps
When refering to files and directories inside of the top-level "deps/"
directory, we're being inconsistent in using relative or absolute paths.
To enable splitting out parts of the top-level CMakeLists.txt into an
own file in the "src/" directory, consistently switch over to use
absolute paths to avoid errors when converting.
|
|
|
8341d6cf
|
2017-07-04T10:57:28
|
|
cmake: move regcomp and futimens checks to "features.h"
In our CMakeLists.txt, we have to check multiple functions in order to
determine if we have to use our own or whether we can use the
platform-provided one. For two of these functions, namely `regcomp_l()`
and `futimens`, the defined macro is actually used inside of the header
file "src/unix/posix.h". As such, these macros are not only required by
the library, but also by our test suite, which is makes use of internal
headers.
To prepare for the CMakeLists.txt split, move these two defines inside
of the "features.h" header.
|
|
|
a390a846
|
2017-07-01T13:06:00
|
|
cmake: move defines into "features.h" header
In a future commit, we will split out the build instructions for our
library directory and move them into a subdirectory. One of the benefits
is fixing scoping issues, where e.g. defines do not leak to build
targets where they do not belong to. But unfortunately, this does also
pose the problem of how to propagate some defines which are required by
both the library and the test suite.
One way would be to create another variable keeping track of all added
defines and declare it inside of the parent scope. While this is the
most obvious and simplest way of going ahead, it is kind of unfortunate.
The main reason to not use this is that these defines become implicit
dependencies between the build targets. By simply observing a define
inside of the CMakeLists.txt file, one cannot reason whether this define
is only required by the current target or whether it is required by
different targets, as well.
Another approach would be to use an internal header file keeping track
of all defines shared between targets. While configuring the library, we
will set various variables and let CMake configure the file, adding or
removing defines based on what has been configured. Like this, one can
easily keep track of the current environment by simply inspecting the
header file. Furthermore, these dependencies are becoming clear inside
the CMakeLists.txt, as instead of simply adding a define, we now call
e.g. `SET(GIT_THREADSAFE 1)`.
Having this header file though requires us to make sure it is always
included before any "#ifdef"-preprocessor checks are executed. As we
have already refactored code to always include the "common.h" header
file before any statement inside of a file, this becomes easy: just make
sure "common.h" includes the new "features.h" header file first.
|
|
|
35087f0e
|
2017-06-28T15:42:54
|
|
cmake: create separate CMakeLists.txt for tests
Our CMakeLists.txt is very unwieldy in its current size, spanning more
than 700 lines of code. Furthermore, it has several issues regarding
scoping, where for example some defines, includes, etc. from our test
suite are also applied to our normal library code.
To fix this, we can separate out build instructions for our tests and
move them into their own CMakeLists.txt in the "tests" directory. This
reduced complexity of the root CMakeLists.txt file and fixes the issues
regarding leaking build context from tests into the library.
|
|
|
3267115f
|
2017-06-28T15:41:15
|
|
cmake: create own precompiled headers for tests
As soon as we split up our CMakeBuild.txt build instructions, we will be
unable to simply link against the git2 library's precompiled header from
other targets. To avoid this future breakage, create a new precompiled
header for our test suite. Next to being compatible with the split, this
enables us to also include additional files like the clar headers, which
may help speeding up compilation of the test suite.
|
|
|
caab8270
|
2017-06-23T19:07:01
|
|
cmake: create object library target
Currently, we're compiling our library code twice, once as part of the
libgit2 library and once for the libgit2_clar executable. Since CMake
2.8.8, there exists a new library type OBJECT, which represents an
intermediate target which can then subsequently be used when linking
several targets against the same set of objects.
Use an OBJECT library to create an internal library for linking. This
new target is only used on CMake v2.8.8 or newer. As CMake 3.0 changed
the way how generator expressions are evaluated when accessing
properties, we need to enable CMake policy 0051 to keep
`IDE_SPLIT_SOURCES` functioning.
|
|
|
f33911e5
|
2017-06-23T18:32:48
|
|
cmake: remove unused variable "CLAR_RESOURCES"
Once upon a time, the `CLAR_RESOURCES` variable was intended to set
the `CLAR_RESOURCES` define. But actually, the define uses a wrong
variable name by accident, hinting that its value cannot actually be
used at all, as it is empty. Searching through the code base confirms
the guess that the define is not used at all.
Remove both the variable and definition.
|
|
|
096a49c0
|
2017-07-03T08:45:57
|
|
cmake: try to detect threads library
While we already make use of the variable `${CMAKE_THREAD_LIBS_INIT}`,
it is actually undefined due to us never including the "FindThreads"
module in the CMakeLists.txt. It is rather curious as to why this has
never triggered any error up to now, but it does in fact result in
linking errors on some Unix platforms as soon as we split up our build
instructions into multiple files.
Fix the issue now to avoid future breakage by including the
"FindThreads" module.
|
|
|
56893bb9
|
2017-06-28T12:11:44
|
|
cmake: consistently use TARGET_INCLUDE_DIRECTORIES if available
Instead of using INCLUDE_DIRECTORIES again for the libgit2_clar test
suite, we should just be using TARGET_INCLUDE_DIRECTORIES again if the
CMake version is greater than 2.8.11.
|
|
22de81e6
|
2017-06-21T08:25:36
|
|
cmake: use `target_include_directories` for modern cmake
Apply `target_include_directories` when CMAKE_VERSION >= 2.8.12
|
|
|
6b2133b4
|
2017-06-27T12:46:15
|
|
Merge pull request #4235 from pks-t/pks/out-of-tree-builds
Out of tree builds
|
|
|
4305fcca
|
2017-05-10T12:14:36
|
|
cmake: generate clar.suite in binary directory
Change the output path of generate.py to generate the clar.suite file
inside of the binary directory. This fixes out of tree builds with
read-only source trees as we now refrain from writing anything into the
source tree.
|
|
845f661d
|
2017-06-21T20:02:48
|
|
cmake: Permit disabling external http-parser
When attempting to build libgit2 as an isolated static lib, CMake
gleefully attempts to use the system http-parser. This is typically
seen on Linux systems which install header files with every package,
such as Gentoo.
Allow developers to forcibly disable using the system http-parser with
the config switch USE_EXT_HTTP_PARSER. Defaults to ON to maintain
previous behavior.
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
|
|
a64532e1
|
2017-06-13T11:05:09
|
|
cmake: disable optimization on debug builds
While our debug builds on MSVC platforms already tune the code optimizer
to aid debugging code, all the other platforms still use the default
optimization level. This makes it hard for developers on these platforms
to actually debug code while maintaining his sanity due to optimizations
like inlined code, elided variables etc.
To help this common use case, we can simply follow the MSVC example and
turn off code optimization with "-O0" for debug builds. While it would
be preferable to instead use "-Og" supported by more modern compilers,
we cannot guarantee that this level is available on all supported
platforms.
|
|
|
61399953
|
2017-06-13T11:03:38
|
|
cmake: set "-D_DEBUG" on non-Windows platforms
In our code base, we have some occasions where we use the "_DEBUG"
preprocessor macro to enable additional code which should not be part of
release builds. While we define this flag on MSVC platforms, it is
guarded by the conditional `WIN32 AND NOT CYGWIN` on other platforms
since 19be3f9e6 (Improve MSVC compiler, linker flags, 2013-02-13). While
this condition can be fulfilled by the MSVC platform, it is never
encountered due to being part of the `ELSE` part of `IF (MSVC)`.
The intention of the conditional was most likely to avoid the
preprocessor macro on Cygwin platforms, but to include it on everthing
else. As such, the correct condition here would be `IF (NOT CYGWIN)`
instead. But digging a bit further, the condition is only ever used in
two places:
1. To skip the test in "core::structinit", which should also work on
Cygwin.
2. In "src/win32/git2.rc", where it is used to set additional file
flags. As this file is included in MSVC builds only, it cannot cause
any harm to set "_DEBUG" on Cygwin here.
As such, we can simply drop the conditional and always set "-D_DEBUG" on
all platforms.
|
|
|
e94be4c0
|
2017-06-13T11:08:19
|
|
cmake: remove stale comment on precompiled headers
In commit 9f75a9ce7 (Turning on runtime checks when building debug under
MSVC., 2012-03-30), we introduced a comment "Precompiled headers", which
actually refers to no related commands. Seeing that the comment never
had anything to refer to, we can simply remove it here.
|
|
|
db1abffa
|
2017-06-07T14:59:38
|
|
sha1dc: do not use standard includes
The updated SHA1DC library allows us to use custom includes instead of
using standard includes. Due to requirements with cross-platform, we
provide some custom system includes files like for example the
"stdint.h" file on Win32. Because of this, we want to make sure to avoid
breaking cross-platform compatibility when SHA1DC is enabled.
To use the new mechanism, we can simply define
`SHA1DC_NO_STANDARD_INCLUDES`. Furthermore, we can specify custom
include files via two defines, which we now use to include our
"common.h" header.
|
|
|
f218508f
|
2017-06-07T10:54:48
|
|
ctest: temporarily disable UNC path tests
(Temporarily) disable UNC path tests to work around AppVeyor issues.
|
|
|
a4de1ae3
|
2017-04-25T10:14:19
|
|
cmake: define GIT_HTTPS when HTTPS is supported
|
|
9f128d2a
|
2017-03-02T20:56:47
|
|
cmake: drop unset `SHA1_TYPE`
We never set `SHA1_TYPE` to `builtin`. Don't bother testing for it.
|
|
|
2dfd1294
|
2017-02-24T13:34:01
|
|
hash: include sha1collisiondetection
Include the SHA1 collision attack detection library from
https://github.com/cr-marcstevens/sha1collisiondetection
|
|
|
a371a8ae
|
2017-02-24T13:03:15
|
|
hash: rename implementation selection constants
|
|
|
a02e8a38
|
2017-03-01T13:58:15
|
|
cmake: only enable supported compiler warning flags
We currently unconditionally enable the "-Wall" and "-Wextra" flags.
Some platforms rely on compilers which do not support these flags,
though. One of these platforms is Haiku, which does not support
"-Wextra" due to being stuck on GCC version 2.
Fix builds on such platforms by adding these flags only if supported by
the compiler.
|
|
e56e4c76
|
2016-12-30T17:59:47
|
|
CMakeLists: Move `http-parser` block down by `zlib`, update error message
|
|
|
236a690c
|
2016-11-20T22:46:01
|
|
Allow Windows with WinHTTP to use external http-parser
|
|
36117978
|
2016-10-06T18:30:30
|
|
Fix the existence check for `regcomp_l`.
`xlocale.h` only defines `regcomp_l` if `regex.h` was included as well.
Also change the test cases to actually test `p_regcomp` works with
a multibyte locale.
|
|
|
ab96ca55
|
2016-10-06T13:15:31
|
|
Make sure we use the `C` locale for `regcomp` on macOS.
|
|
|
528b2f7d
|
2016-09-05T13:24:07
|
|
cmake: add curl library path
The `PKG_CHECK_MODULES` function searches a pkg-config module and
then proceeds to set various variables containing information on
how to link to the library. In contrast to the `FIND_PACKAGE`
function, the library path set by `PKG_CHECK_MODULES` will not
necessarily contain linking instructions with a complete path to
the library, though. So when a library is not installed in a
standard location, the linker might later fail due to being
unable to locate it.
While we already honor this when configuring libssh2 by adding
`LIBSSH2_LIBRARY_DIRS` to the link directories, we fail to do so
for libcurl, preventing us to build libgit2 on e.g. FreeBSD. Fix
the issue by adding the curl library directory to the linker
search path.
|
|
|
b6a2fd0e
|
2016-06-20T11:09:49
|
|
cmake: do not use -fPIC for MSYS2
The MSYS2 build system automatically compiles all code with position-independent
code. When we manually add the -fPIC flag to the compiler flags, MSYS2 will
loudly complain about PIC being the default and thus not required.
Fix the annoyance by stripping -fPIC in MSYS2 enviroments like it is already
done for MinGW.
|
|
|
0aaba445
|
2016-06-01T11:33:58
|
|
Merge pull request #3796 from mmuman/haiku
Preliminary Haiku port
|
|
13b0b7d5
|
2016-05-27T10:20:35
|
|
Update CMakeLists.txt
typo fix
|
|
d94f5037
|
2016-05-22T23:23:58
|
|
CMakeLists: Add libnetwork for Haiku
|