|
9e07f684
|
2019-04-26T08:01:56
|
|
cmake: fix include ordering issues with bundled deps
When linking against bundled libraries, we include their header
directories by using "-isystem". The reason for that is that we
want to handle our vendored library headers specially, most
importantly to ignore warnings generated by including them. By
using "-isystem", though, we screw up the order of searched
include directories by moving those bundled dependencies towards
the end of the lookup order. Like this, chances are high that any
other specified include directory contains a file that collides
with the actual desired include file.
Fix this by not treating the bundled dependencies' include
directories as system includes. This will move them to the front
of the lookup order and thus cause them to override
system-provided headers. While this may cause the compiler to
generate additional warnings when processing bundled headers,
this is a tradeoff we should make regardless to fix builds on
systems hitting this issue.
(cherry picked from commit ee3d71fb86bad4a681d762d90374e46f1d005714)
|
|
|
085ed2c6
|
2019-02-25T11:35:16
|
|
cmake: correctly detect if system provides `regcomp`
We assume that if we are on Win32, Amiga OS, Solaris or SunOS,
that the regcomp(3P) function cannot be provided by the system.
Thus we will in these cases always include our own, bundled regex
sources to make a regcomp implementation available. This test is
obviously very fragile, and we have seen it fail on MSYS2/MinGW
systems, which do in fact provide the regcomp symbol. The effect
is that during compilation, we will use the "regex.h" header
provided by MinGW, but use symbols provided by ourselves. This
in fact may cause subtle memory layout issues, as the structure
made available via MinGW doesn't match what our bundled code
expects.
There's one more problem with our regex detection: on the listed
platforms, we will incorrectly include the bundled regex code
even in case where the system provides regcomp_l(3), but it will
never be used for anything.
Fix the issue by improving our regcomp detection code. Instead of
relying on a fragile listing of platforms, we can just use
`CHECK_FUNCTION_EXISTS` instead. This will not in fact avoid the
header-ordering problem. But we can assume that as soon as a
system-provided "regex.h" header is provided, that
`CHECK_FUNCTION_EXISTS` will now correctly find the desired
symbol and thus not include our bundled regex code.
(cherry picked from commit 13cb9f7a3325e71a01073647d1c23f49464f200e)
|
|
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.
|
|
|
b8bdffb5
|
2018-07-02T07:27:09
|
|
cmake: increase WIN32_WINNT to Vista
Increase the WIN32_WINNT level to 0x0600, which enables support for new
APIs from Windows 6.0 (Vista). We had previously set this to 0x0501,
which was Windows XP. Although we removed XP support many years ago,
there was no need to update this level previously. We're doing so now
explicitly so that we can get support for the `CreateSymbolicLink` API.
|
|
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.
|
|
|
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.
|
|
|
c13e56f9
|
2018-06-25T14:12:53
|
|
cmake: distinguish internal and system include directories
While we want to enforce strict C90 mode, this may cause issues with
system provided header files which are themselves not strictly
conforming. E.g. if a system header has C++ style comments, a compiler
in strict C90 mode would produce an error and abort the build. As the
user most likely doesn't want to change the system header, this would
completely break the build on such systems. One example of this is
mbedtls, which provides such header files.
The problem can be worked around by distinguishing between
system-provided and project-provided include directories. When adding
include directories via "-isystem" instead of "-I", the compiler will
skip certain checks and print out less warnings. To use system includes,
we can simply add the "SYSTEM" flag to CMake's `INCLUDE_DIRECTORIES` and
`TARGET_INCLUDE_DIRECTORIES` functions. Note that we have to split the
include directories into two variables because of this, as we definitely
still want to check for all warnings produced by our own header files.
|
|
b89162af
|
2018-06-10T17:26:08
|
|
Link `mbedTLS` libraries in when `SHA1_BACKEND == "mbedTLS"`
|
|
|
90c6fb0f
|
2018-06-10T17:33:06
|
|
Fix typo in adding `hash_mbedtls.c` to `SRC_SHA1`
|
|
|
64a78a80
|
2018-05-25T09:28:52
|
|
mbedtls: don't require mbedtls from our pkgconfig file
mbedTLS has no pkgconfig file, hence we can't require it. For now, pass its link flags as our own.
|
|
|
8ab470f5
|
2018-04-27T15:31:43
|
|
cmake: remove now-useless LIBGIT2_LIBDIRS handling
With the recent change of always resolving pkg-config libraries to their
full path, we do not have to manage the LIBGIT2_LIBDIRS variable
anymore. The only other remaining user of LIBGIT2_LIBDIRS is winhttp,
which is a CMake-style library target and can thus be resolved by CMake
automatically.
Remove the variable to simplify our build system a bit.
|
|
|
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`.
|
|
|
54554757
|
2018-03-29T22:14:14
|
|
cmake: make our preferred backend ordering consistent
|
|
|
382ed1e8
|
2018-03-29T22:14:09
|
|
mbedtls: load default CA certificates
|
|
|
6c6be3ce
|
2018-03-29T22:13:59
|
|
mbedtls: use libmbedcrypto for hashing
|
|
|
ca3b2234
|
2018-03-29T22:13:56
|
|
mbedtls: initial support
|
|
b21c5408
|
2018-01-08T12:33:07
|
|
cmake: add openssl to the private deps list when it's the TLS implementation
We might want OpenSSL to be the implementation for SHA-1 and/or TLS. If we only
want it for TLS (e.g. we're building with the collision-detecting SHA-1
implementation) then we did not indicate this to the systems including us a
static library.
Add OpenSSL to the list also during the TLS decision to make sure we say we
should link to it if we use it for TLS.
|
|
|
b85548ed
|
2018-01-08T12:30:50
|
|
cmake: treat LIBGIT2_PC_REQUIRES as a list
It is indeed a list of dependencies for those which include the static archive.
This is in preparation for adding two possible places where we might add openssl
as a dependency.
|
|
|
70db57d4
|
2018-01-05T15:31:51
|
|
Merge pull request #4398 from pks-t/pks/generic-sha1
cmake: allow explicitly choosing SHA1 backend
|
|
|
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.
|
|
|
30455a56
|
2018-01-03T13:09:21
|
|
Merge pull request #4439 from tiennou/fix/4352
cmake: create a dummy file for Xcode
|
|
|
4969a672
|
2017-12-10T02:19:34
|
|
cmake: create a dummy file for Xcode
Otherwise Xcode will happily not-link our git2 target, resulting in a "missing file" error when building eg. examples
|
|
|
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.
|
|
|
fdd06874
|
2017-08-09T21:35:53
|
|
cmake: use FeatureSummary to display which features we end up using
|
|
|
99d6ebb3
|
2017-09-06T22:01:50
|
|
cmake: make our macOS helpers more CMake-y
|
|
|
e9369856
|
2017-03-21T00:25:15
|
|
stream: Gather streams to src/streams
|
|
|
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}`.
|
|
|
0e709032
|
2017-10-09T10:55:02
|
|
cmake: fix linking in Xcode with object libraries only
CMake is unable to generate a correct Xcode project when trying to link
libraries with only object libraries as its input. As our new build
infrastructure makes heavy use of object libraries now, this affects our
libgit2 library target, as well, leading to linking errors.
Fix the issue by adding a dummy file to the libgit2 objects. As we
always have the "features.h" header ready which contains defines only,
we can simply link it into the resulting library without any effect
whatsoever. This fixes building with Xcode.
|
|
|
8c19969a
|
2017-09-06T07:38:48
|
|
cmake: fix static linking for bundled deps
Our bundled deps are being built as simple static libraries which are
then linked into the libgit2 library via `TARGET_LINK_LIBRARIES`. While
this works for a dynamically built libgit2 library, using this function
to link two static libraries does not have the expected outcome of
merging those static libraries into one big library. This leads to
symbols of our bundled deps being undefined in the resulting libgit2
archive.
As we have bumped our minimum CMake version to 2.8.11, we can now easily
make use of object libraries for our bundled dependencies. So build
instructions are still self-contained inside of the dependency
directories and the resulting object libraries can just be added to the
LIBGIT2_OBJECTS list, which will cause them to be linked into the final
resulting static library. This fixes the issue of undefined symbols.
|
|
|
172a585f
|
2017-09-05T15:09:34
|
|
cmake: always use object library for git2internal
As we have bumped our minimum CMake version to 2.8.11, we can now
unconditionally make use of object libraries. So remove the version
check for the git2internal object library and always use it.
|
|
|
1d9dd882
|
2017-09-05T15:06:29
|
|
cmake: distinguish libgit2 objects and sources
Distinguish variables keeping track of our internal libgit2 sources and
the final objects which shall be linked into the library. This will ease
the transition to use object libraries for our bundled dependencies
instead of linking them in.
|
|
|
a3a35473
|
2017-08-17T08:38:47
|
|
cmake: fix output location of import libraries and DLLs
As observed by Edward Thomson, the libgit2 DLL built by Windows will not
end up in the top-level build directory but instead inside of the 'src/'
subdirectory. While confusing at first because we are actually setting
the LIBRARY_OUTPUT_DIRECTORY to the project's binary directory, the
manual page of LIBRARY_OUTPUT_DIRECTORY clears this up:
There are three kinds of target files that may be built: archive,
library, and runtime. Executables are always treated as runtime
targets. Static libraries are always treated as archive targets.
Module libraries are always treated as library targets. For non-DLL
platforms shared libraries are treated as library targets. For DLL
platforms the DLL part of a shared library is treated as a runtime
target and the corresponding import library is treated as an archive
target. All Windows-based systems including Cygwin are DLL
platforms.
So in fact, DLLs and import libraries are not treated as libraries at
all by CMake but instead as runtime and archive targets. To fix the
issue, we can thus simply set the variables RUNTIME_OUTPUT_DIRECTORY and
ARCHIVE_OUTPUT_DIRECTORY to the project's root binary directory.
|
|
|
8a43161b
|
2017-07-05T12:18:17
|
|
cmake: always include our own headers first
With c26ce7840 (Merge branch 'AndreyG/cmake/modernization', 2017-06-28),
we have recently introduced a regression in the way we are searching for
headers. We have made sure to always include our own headers first, but
due to the changes in c26ce7840 this is no longer guaranteed. In fact,
this already leads the compiler into picking "config.h" from the
"deps/regex" dependency, if it is used.
Fix the issue by declaring our internal include directories up front,
before any of the other search directories is added.
|
|
|
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.
|