kmx git

Commit	Date	Message
9ceafb57	2019-01-12T22:55:31	regexec: use pcre as our fallback/builtin regex Use PCRE 8.42 as the builtin regex implementation, using its POSIX compatibility layer. PCRE uses ASCII by default and the users locale will not influence its behavior, so its `regcomp` implementation is similar to `regcomp_l` with a C locale.
ee3d71fb	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.
13cb9f7a	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.
b63396b7	2019-02-21T12:13:59	allocators: move standard allocator into subdirectory Right now, our two allocator implementations are scattered around the tree in "stdalloc.h" and "win32/w32_crtdbg_stacktrace.h". Start grouping them together in a single directory "allocators/", similar to how e.g. our streams are organized.
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.

9ceafb57

2019-01-12T22:55:31

regexec: use pcre as our fallback/builtin regex Use PCRE 8.42 as the builtin regex implementation, using its POSIX compatibility layer. PCRE uses ASCII by default and the users locale will not influence its behavior, so its `regcomp` implementation is similar to `regcomp_l` with a C locale.

ee3d71fb

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.

13cb9f7a

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.

b63396b7

2019-02-21T12:13:59

allocators: move standard allocator into subdirectory Right now, our two allocator implementations are scattered around the tree in "stdalloc.h" and "win32/w32_crtdbg_stacktrace.h". Start grouping them together in a single directory "allocators/", similar to how e.g. our streams are organized.

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.

thodg/libgit2/src/CMakeLists.txt

src/CMakeLists.txt

Log