thodg/libgit2/src/CMakeLists.txt

src/CMakeLists.txt

Log

Author Commit Date CI Message
Julien Richard 2dbe413e 2021-08-17T11:34:11 Fix LIBGIT2_FILENAME not being passed to the resource compiler
Edward Thomson 3062a633 2021-07-30T12:03:35 cmake: extended futimens checking on macOS
Edward Thomson 48e6b02b 2021-07-19T15:41:44 alloc: add GIT_DEBUG_STRICT_ALLOC Add `GIT_DEBUG_STRICT_ALLOC` to help identify problematic callers of allocation code that pass a `0` size to the allocators and then expect a non-`NULL` return. When given a 0-size allocation, `malloc` _may_ return either a `NULL` _or_ a pointer that is not writeable. Most systems return a non-`NULL` pointer; AIX is an outlier. We should be able to cope with this AIXy behavior, so this adds an option to emulate it.
lhchavez 754fa526 2021-01-04T06:10:10 Use an option instead of a flag for USE_BUNDLED_ZLIB Now `USE_BUNDLED_ZLIB` can be set to the string `Chromium` to enable the Chromium implementation of zlib.
lhchavez 83265b3e 2020-12-18T06:50:22 zlib: Add support for building with Chromium's zlib implementation This change builds libgit2 using Chromium's zlib implementation by invoking cmake with `-DUSE_BUNDLED_ZLIB=ON -DUSE_CHROMIUM_ZLIB=ON`, which is ~10% faster than the bundled zlib for the core::zstream suite. This version of zlib has some optimizations: a) Decompression (Intel+ARM): inflate_fast, adler32, crc32, etc. b) Compression (Intel): fill_window, longest_match, hash function, etc. Due to the introduction of SIMD optimizations, and to get the maximum performance out of this fork of zlib, this requires an x86_64 processor with SSE4.2 and CLMUL (anything Westmere or later, ~2010). The Chromium zlib implementation also supports ARM with NEON, but it has not been enabled in this patch. Performance =========== TL;DR: Running just `./libgit2_clar -score::zstream` 100 times in a loop took 0:56.30 before and 0:50.67 after (~10% reduction!). The bundled and system zlib implementations on an Ubuntu Focal system perform relatively similar (the bundled one is marginally better due to the compiler being able to inline some functions), so only the bundled and Chromium zlibs were compared. For a more balanced comparison (to ensure that nothing regressed overall), `libgit2_clar` under `perf` was also run, and the zlib-related functions were compared. Bundled ------- ```shell cmake \ -DUSE_BUNDLED_ZLIB=ON \ -DUSE_CHROMIUM_ZLIB=OFF \ -DCMAKE_BUILD_TYPE="RelWithDebInfo" \ -DCMAKE_C_FLAGS="-fPIC -fno-omit-frame-pointer" \ -GNinja \ .. ninja perf record --call-graph=dwarf ./libgit2_clar perf report --children ``` ``` Samples: 87K of event 'cycles', Event count (approx.): 75923450603 Children Self Command Shared Objec Symbol + 4.14% 0.01% libgit2_clar libgit2_clar [.] git_zstream_get_output_chunk + 2.91% 0.00% libgit2_clar libgit2_clar [.] git_zstream_get_output + 0.69% 0.00% libgit2_clar libgit2_clar [.] git_zstream_get_output (inlined) 0.17% 0.00% libgit2_clar libgit2_clar [.] git_zstream_init 0.02% 0.00% libgit2_clar libgit2_clar [.] git_zstream_reset 0.00% 0.00% libgit2_clar libgit2_clar [.] git_zstream_eos 0.00% 0.00% libgit2_clar libgit2_clar [.] git_zstream_done 0.00% 0.00% libgit2_clar libgit2_clar [.] git_zstream_free (inlined) Samples: 87K of event 'cycles', Event count (approx.): 75923450603 Children Self Command Shared Objec Symbol + 3.12% 0.01% libgit2_clar libgit2_clar [.] deflate + 2.65% 1.48% libgit2_clar libgit2_clar [.] deflate_slow + 1.60% 0.55% libgit2_clar libgit2_clar [.] inflate + 0.53% 0.00% libgit2_clar libgit2_clar [.] write_deflate 0.49% 0.36% libgit2_clar libgit2_clar [.] inflate_fast 0.46% 0.02% libgit2_clar libgit2_clar [.] deflate_fast 0.19% 0.19% libgit2_clar libgit2_clar [.] inflate_table 0.16% 0.01% libgit2_clar libgit2_clar [.] inflateInit_ 0.15% 0.00% libgit2_clar libgit2_clar [.] inflateInit2_ (inlined) 0.10% 0.00% libgit2_clar libgit2_clar [.] deflateInit_ 0.10% 0.00% libgit2_clar libgit2_clar [.] deflateInit2_ 0.03% 0.00% libgit2_clar libgit2_clar [.] deflateReset (inlined) 0.02% 0.00% libgit2_clar libgit2_clar [.] deflateReset 0.02% 0.00% libgit2_clar libgit2_clar [.] inflateEnd 0.02% 0.00% libgit2_clar libgit2_clar [.] deflateEnd 0.01% 0.00% libgit2_clar libgit2_clar [.] deflateResetKeep 0.01% 0.01% libgit2_clar libgit2_clar [.] inflateReset2 0.01% 0.00% libgit2_clar libgit2_clar [.] deflateReset (inlined) 0.00% 0.00% libgit2_clar libgit2_clar [.] inflateStateCheck (inlined) 0.00% 0.00% libgit2_clar libgit2_clar [.] inflateReset (inlined) 0.00% 0.00% libgit2_clar libgit2_clar [.] inflateStateCheck (inlined) 0.00% 0.00% libgit2_clar libgit2_clar [.] deflateStateCheck (inlined) 0.00% 0.00% libgit2_clar libgit2_clar [.] inflateResetKeep (inlined) ``` Chromium -------- ```shell cmake \ -DUSE_BUNDLED_ZLIB=ON \ -DUSE_CHROMIUM_ZLIB=ON \ -DCMAKE_BUILD_TYPE="RelWithDebInfo" \ -DCMAKE_C_FLAGS="-fPIC -fno-omit-frame-pointer" \ -GNinja \ .. ninja perf record --call-graph=dwarf ./libgit2_clar perf report --children ``` ``` Samples: 97K of event 'cycles', Event count (approx.): 80862210917 Children Self Command Shared Objec Symbol + 3.31% 0.00% libgit2_clar libgit2_clar [.] git_zstream_get_output_chunk + 2.27% 0.01% libgit2_clar libgit2_clar [.] git_zstream_get_output + 0.55% 0.00% libgit2_clar libgit2_clar [.] git_zstream_get_output (inlined) 0.18% 0.00% libgit2_clar libgit2_clar [.] git_zstream_init 0.02% 0.00% libgit2_clar libgit2_clar [.] git_zstream_reset 0.00% 0.00% libgit2_clar libgit2_clar [.] git_zstream_free (inlined) 0.00% 0.00% libgit2_clar libgit2_clar [.] git_zstream_done 0.00% 0.00% libgit2_clar libgit2_clar [.] git_zstream_free Samples: 97K of event 'cycles', Event count (approx.): 80862210917 Children Self Command Shared Objec Symbol + 2.55% 0.01% libgit2_clar libgit2_clar [.] deflate + 2.25% 1.41% libgit2_clar libgit2_clar [.] deflate_slow + 1.10% 0.52% libgit2_clar libgit2_clar [.] inflate 0.36% 0.00% libgit2_clar libgit2_clar [.] write_deflate 0.30% 0.03% libgit2_clar libgit2_clar [.] deflate_fast 0.28% 0.15% libgit2_clar libgit2_clar [.] inflate_fast_chunk_ 0.19% 0.19% libgit2_clar libgit2_clar [.] inflate_table 0.17% 0.01% libgit2_clar libgit2_clar [.] inflateInit_ 0.16% 0.00% libgit2_clar libgit2_clar [.] inflateInit2_ (inlined) 0.15% 0.00% libgit2_clar libgit2_clar [.] deflateInit_ 0.15% 0.00% libgit2_clar libgit2_clar [.] deflateInit2_ 0.11% 0.01% libgit2_clar libgit2_clar [.] adler32_z 0.09% 0.09% libgit2_clar libgit2_clar [.] adler32_simd_ 0.05% 0.00% libgit2_clar libgit2_clar [.] deflateReset (inlined) 0.05% 0.00% libgit2_clar libgit2_clar [.] deflate_read_buf 0.03% 0.00% libgit2_clar libgit2_clar [.] inflateEnd 0.02% 0.00% libgit2_clar libgit2_clar [.] deflateReset 0.01% 0.00% libgit2_clar libgit2_clar [.] deflateEnd 0.01% 0.01% libgit2_clar libgit2_clar [.] inflateReset2 0.01% 0.00% libgit2_clar libgit2_clar [.] inflateReset (inlined) 0.00% 0.00% libgit2_clar libgit2_clar [.] adler32 0.00% 0.00% libgit2_clar libgit2_clar [.] inflateResetKeep (inlined) 0.00% 0.00% libgit2_clar libgit2_clar [.] deflateResetKeep 0.00% 0.00% libgit2_clar libgit2_clar [.] inflateStateCheck (inlined) 0.00% 0.00% libgit2_clar libgit2_clar [.] inflateStateCheck (inlined) 0.00% 0.00% libgit2_clar libgit2_clar [.] inflateStateCheck (inlined) 0.00% 0.00% libgit2_clar libgit2_clar [.] deflateStateCheck (inlined) ```
Patrick Steinhardt 4218403e 2020-06-05T10:49:09 cmake: use target-specific compile definitions We set up some compile definitions as part of our src/CMakeLists.txt. While the definitions are global, we really only need them as part of the git2internal target which compiles all the objects. Let's thus use `target_compile_definitions` instead of `add_definitions`.
Patrick Steinhardt 53911edd 2020-06-05T10:24:30 cmake: use git2internal target to populate sources Modern CMake is usually target-driven in that a target is first defined and then the likes of `target_sources`, `target_include_directories` etc. are used to further populate the target. We still use old-style CMake, where we first set up a set of variables and then populate the target in a single call. Let's migrate to modern CMake usage by starting to populate the sources of our git2internal target piece-by-piece. While this is a small step, it allows us to convert to target-based build instructions piece-by-piece.
Patrick Steinhardt 19eb1e4b 2020-06-05T10:07:33 cmake: specify project version We currently do not set up a project version within CMake, meaning that it can't be use by other projects including libgit2 as a sub-project and also not by other tools like IDEs. This commit changes this to always set up a project version, but instead of extracting it from the "version.h" header we now set it up directly. This is mostly to avoid mis-use of the previous `LIBGIT2_VERSION` variables, as we should now always use the `libgit2_VERSION` ones that are set up by CMake if one provides the "VERSION" keyword to the `project()` call. While this is one more moving target we need to adjust on releases, this commit also adjusts our release script to verify that the project version was incremented as expected.
Alexander Ovchinnikov dc1deb3b 2020-07-01T15:41:38 Use __GNUC__ macro in the resource script Fix the default LIBGIT2_FILENAME for GNU windres
Alexander Ovchinnikov 5c40456b 2020-06-16T13:19:02 Enable building git2.rc resource script with GCC
Patrick Steinhardt 03c4f86c 2020-06-08T12:42:59 cmake: enable warnings for missing function declarations Over time, we have accumulated quite a lot of functions with missing prototypes, missing `static` keywords or which were completely unused. It's easy to miss these mistakes, but luckily GCC and Clang both have the `-Wmissing-declarations` warning. Enabling this will cause them to emit warnings for every not-static function that doesn't have a previous declaration. This is a very sane thing to enable, and with the preceding commits all these new warnings have been fixed. So let's always enable this warning so we won't introduce new instances of them.
Patrick Steinhardt b85eefb4 2020-05-15T19:52:40 cmake: Sort source files for reproducible builds We currently use `FILE(GLOB ...)` in most places to find source and header files. This is problematic in that the order of files returned depends on the operating system's directory iteration order and may thus not be deterministic. As a result, we link object files in unspecified order, which may cause the linker to emit different code across runs. Fix this issue by sorting all code used as input to the libgit2 library to improve the reliability of reproducible builds.
Edward Thomson 9a102446 2020-03-21T16:49:44 Merge pull request #5455 from pks-t/pks/cmake-install-dirs cmake: use install directories provided via GNUInstallDirs
Patrick Steinhardt 87fc539f 2020-03-13T22:08:19 cmake: use install directories provided via GNUInstallDirs We currently hand-code logic to configure where to install our artifacts via the `LIB_INSTALL_DIR`, `INCLUDE_INSTALL_DIR` and `BIN_INSTALL_DIR` variables. This is reinventing the wheel, as CMake already provide a way to do that via `CMAKE_INSTALL_<DIR>` paths, e.g. `CMAKE_INSTALL_LIB`. This requires users of libgit2 to know about the discrepancy and will require special hacks for any build systems that handle these variables in an automated way. One such example is Gentoo Linux, which sets up these paths in both the cmake and cmake-utils eclass. So let's stop doing that: the GNUInstallDirs module handles it in a better way for us, especially so as the actual values are dependent on CMAKE_INSTALL_PREFIX. This commit removes our own set of variables and instead refers users to use the standard ones. As a second benefit, this commit also fixes our pkgconfig generation to use the GNUInstallDirs module. We had a bug there where we ignored the CMAKE_INSTALL_PREFIX when configuring the libdir and includedir keys, so if libdir was set to "lib64", then libdir would be an invalid path. With GNUInstallDirs, we can now use `CMAKE_INSTALL_FULL_LIBDIR`, which handles the prefix for us.
Patrick Steinhardt b1f6481f 2020-03-10T22:07:35 cmake: ignore deprecation notes for Secure Transport The Secure Transport interface we're currently using has been deprecated with macOS 10.15. As we're currently in code freeze, we cannot migrate to newer interfaces. As such, let's disable deprecation warnings for our "schannel.c" stream.
Edward Thomson e23b8b44 2020-03-06T17:13:48 Merge pull request #5422 from pks-t/pks/cmake-booleans CMake booleans
Igor Gnatenko dd704944 2020-03-03T11:05:04 Set proper pkg-config dependency for pcre2 Signed-off-by: Igor Raits <i.gnatenko.brain@gmail.com>
Patrick Steinhardt d8e71cb2 2020-02-24T21:07:34 cmake: fix ENABLE_TRACE parameter being too strict In order to check whether tracing support should be turned on, we check whether ENABLE_TRACE equals "ON". This is being much too strict, as CMake will also treat "on", "true", "yes" and others as true-ish, but passing them will disable tracing support now. Fix the issue by simply removing the STREQUAL, which will cause CMake to do the right thing automatically.
Patrick Steinhardt 877054f3 2020-02-10T12:35:13 cmake: consolidate Valgrind option OpenSSL doesn't initialize bytes on purpose in order to generate additional entropy. Valgrind isn't too happy about that though, causing it to generate warninings about various issues regarding use of uninitialized bytes. We traditionally had some infrastructure to silence these errors in our OpenSSL stream implementation, where we invoke the Valgrind macro `VALGRIND_MAKE_MEMDEFINED` in various callbacks that we provide to OpenSSL. Naturally, we only include these instructions if a preprocessor define "VALGRIND" is set, and that in turn is only set if passing "-DVALGRIND" to CMake. We do that in our usual Azure pipelines, but we in fact forgot to do this in our nightly build. As a result, we get a slew of warnings for these nightly builds, but not for our normal builds. To fix this, we could just add "-DVALGRIND" to our nightly builds. But starting with commit d827b11b6 (tests: execute leak checker via CTest directly, 2019-06-28), we do have a secondary variable that directs whether we want to use memory sanitizers for our builds. As such, every user wishing to use Valgrind for our tests needs to pass both options "VALGRIND" and "USE_LEAK_CHECKER", which is cumbersome and error prone, as can be seen by our own builds. Instead, let's consolidate this into a single option, removing the old "-DVALGRIND" one. Instead, let's just add the preprocessor directive if USE_LEAK_CHECKER equals "valgrind" and remove "-DVALGRIND" from our own pipelines.
Edward Thomson cb77423f 2019-11-24T16:22:31 valgrind: add valgrind hints in OpenSSL Provide usage hints to valgrind. We trust the data coming back from OpenSSL to have been properly initialized. (And if it has not, it's an OpenSSL bug, not a libgit2 bug.) We previously took the `VALGRIND` option to CMake as a hint to disable mmap. Remove that; it's broken. Now use it to pass on the `VALGRIND` definition so that sources can provide valgrind hints.
Etienne Samson dbc17a7e 2019-09-21T08:46:08 negotiate: use GSS.framework on macOS
Patrick Steinhardt ebabb88f 2019-10-10T09:25:32 cmake: update minimum CMake version to v3.5.1 Back in commit cf9f34521 (cmake: bump minimum version to 2.8.11, 2017-09-06), we have bumped the minimum CMake version to require at least v2.8.11. The main hold-backs back then were distributions like RHEL/CentOS as well as Ubuntu Trusty, which caused us to not target a more modern version. Nowadays, Ubuntu Trusty has been EOL'd and CentOS 6 has CMake v3.6.1 available via the EPEL6 repository, and thus it seems fair to upgrade to a more recent version. Going through repology [1], one can see that all supported mainstream distributions do in fact have CMake 3 available. Going through the list, the minimum version that is supported by all mainstream distros is in fact v3.5.1: - CentOS 6 via EPEL6: 3.6.1 - Debian Oldstable: 3.7.2 - Fedora 26: 3.8.2 - OpenMandriva 3.x: 3.5.1 - Slackware 14.2: 3.5.2 - Ubuntu 16.04: 3.5.1 Consequentally, let's upgrade CMake to the minimum version of 3.5.1 and remove all the version CMake checks that aren't required anymore. [1]: https://repology.org/project/cmake/versions
Etienne Samson 564b3ffc 2019-08-17T12:34:59 cmake: add missing requires to the .pc file
Etienne Samson d80d9d56 2019-08-17T12:17:21 cmake: streamline *.pc file handling via a module
Tobias Nießen 071750a3 2019-08-15T14:18:26 cmake: move _WIN32_WINNT definitions to root
Edward Thomson cc9e47c9 2019-06-15T18:51:40 win32: support upgrading warnings to errors (/WX) For MSVC, support warnings as errors by providing the /WX compiler flags. (/WX is the moral equivalent of -Werror.) Disable warnings as errors ass part of xdiff, since it contains warnings. But as a component of git itself, we want to avoid skew and keep our implementation as similar as possible to theirs. We'll work with upstream to fix these issues, but in the meantime, simply let those continue to warn.
Etienne Samson 94fc83b6 2019-06-13T16:48:35 cmake: Modulize our TLS & hash detection The interactions between `USE_HTTPS` and `SHA1_BACKEND` have been streamlined. Previously we would have accepted not quite working configurations (like, `-DUSE_HTTPS=OFF -DSHA1_BACKEND=OpenSSL`) and, as the OpenSSL detection only ran with `USE_HTTPS`, the link would fail. The detection was moved to a new `USE_SHA1`, modeled after `USE_HTTPS`, which takes the values "CollisionDetection/Backend/Generic", to better match how the "hashing backend" is selected, the default (ON) being "CollisionDetection". Note that, as `SHA1_BACKEND` is still used internally, you might need to check what customization you're using it for.
Edward Thomson fb529a01 2019-06-11T22:03:29 http-parser: use our bundled http-parser by default Our bundled http-parser includes bugfixes, therefore we should prefer our http-parser until such time as we can identify that the system http-parser has these bugfixes (using a version check). Since these bugs are - at present - minor, retain the ability for users to force that they want to use the system http-parser anyway. This does change the cmake specification so that people _must_ opt-in to the new behavior knowingly.
Edward Thomson a7f65f03 2019-03-21T15:42:57 ntlm: add ntlmclient as a dependency Include https://github.com/ethomson/ntlmclient as a dependency.
Edward Thomson 3d9e82fd 2019-05-21T14:59:55 Merge pull request #4935 from libgit2/ethomson/pcre Use PCRE for our fallback regex engine when regcomp_l is unavailable
Edward Thomson ac2b235e 2019-05-21T12:22:40 regex: use REGEX_BACKEND as the cmake option name This avoids any misunderstanding with the REGEX keyword in cmake.
David Brooks ada1cd01 2019-05-21T21:35:57 Use tabs for indentation (#5079).
David Brooks b575c242 2019-05-21T20:20:04 Fix indentation (#5079).
David Brooks 2c2e924b 2019-05-21T20:17:48 We still need to update pkgconfig variables when zlib is unbundled (#5079).
David Brooks 06dbf734 2019-05-21T15:44:32 We've already added `ZLIB_LIBRARIES` to `LIBGIT2_LIBS` so don't also add the `z` library (libgit2/#5079).
Edward Thomson ce6d624a 2019-05-19T10:30:04 regex: optionally use PCRE2 Use PCRE2 and its POSIX compatibility layer if requested by the user. Although PCRE2 is adequate for our needs, the PCRE2 POSIX layer as installed on Debian and Ubuntu systems is broken, so we do not opt-in to it by default to avoid breaking users on those platforms.
Edward Thomson 69ecdad5 2019-05-19T10:09:55 regex: use system PCRE if available Attempt to locate a system-installed version of PCRE and use its POSIX compatibility layer, if possible.
Edward Thomson 622166c4 2019-05-18T19:37:59 regex: disambiguate builtin vs system pcre
Edward Thomson c6e48fef 2019-02-17T21:51:34 regex: allow regex selection in cmake Users can now select which regex implementation they want to use: one of the system `regcomp_l`, the system PCRE, the builtin PCRE or the system's `regcomp`. By default the system `regcomp_l` will be used if it exists, otherwise the system PCRE will be used. If neither of those exist, then the builtin PCRE implementation will be used. The system's `regcomp` is not used by default due to problems with locales.
Edward Thomson 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Edward Thomson 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.
Edward Thomson 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.
Etienne Samson 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
staticfloat@gmail.com b89162af 2018-06-10T17:26:08 Link `mbedTLS` libraries in when `SHA1_BACKEND == "mbedTLS"`
staticfloat@gmail.com 90c6fb0f 2018-06-10T17:33:06 Fix typo in adding `hash_mbedtls.c` to `SRC_SHA1`
Etienne Samson 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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`.
Etienne Samson 54554757 2018-03-29T22:14:14 cmake: make our preferred backend ordering consistent
Etienne Samson 382ed1e8 2018-03-29T22:14:09 mbedtls: load default CA certificates
Etienne Samson 6c6be3ce 2018-03-29T22:13:59 mbedtls: use libmbedcrypto for hashing
Etienne Samson ca3b2234 2018-03-29T22:13:56 mbedtls: initial support
Carlos Martín Nieto 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.
Carlos Martín Nieto 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.
Edward Thomson 70db57d4 2018-01-05T15:31:51 Merge pull request #4398 from pks-t/pks/generic-sha1 cmake: allow explicitly choosing SHA1 backend
Patrick Steinhardt 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.
Patrick Steinhardt 30455a56 2018-01-03T13:09:21 Merge pull request #4439 from tiennou/fix/4352 cmake: create a dummy file for Xcode
Etienne Samson 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
Edward Thomson 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.
Henry Kleynhans 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
Etienne Samson 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
Etienne Samson 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.
Etienne Samson fdd06874 2017-08-09T21:35:53 cmake: use FeatureSummary to display which features we end up using
Etienne Samson 99d6ebb3 2017-09-06T22:01:50 cmake: make our macOS helpers more CMake-y
Etienne Samson e9369856 2017-03-21T00:25:15 stream: Gather streams to src/streams
Patrick Steinhardt 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}`.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
kmx.io     mail     discord kmxgit v0.4.0