thodg/libgit2/CMakeLists.txt

CMakeLists.txt

Log

Author Commit Date CI Message
Edward Thomson f10c8875 2020-10-11T23:04:08 Release v1.1
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.
Patrick Steinhardt 2551b1b0 2020-04-03T19:53:35 cmake: remove support for creating tags We currently have support for generating tags via ctags as part of our build system. We aren't really in the place of supporting any tooling that exists apart from the actual build environment, as doing so adds additional complexity and maintenance burden to our build instructions. This is in fact nicely demonstrated by this particular option, as it hasn't been working anymore since commit e5c9723d0 (cmake: move library build instructions into subdirectory, 2017-06-30). As a result, this commit removes support for building CTags
Patrick Steinhardt bc02bcd9 2020-04-03T19:51:22 cmake: move modules into the "cmake/" top level dir Our custom CMake module currently live in "cmake/Modules". As the "cmake/" directory doesn't contain anything except the "Modules" directory, it doesn't really make sense to have the additional intermediate directory. So let's instead move the modules one level up into the "cmake/" top level directory.
Patrick Steinhardt 511fb9e6 2020-04-03T22:53:23 cmake: always disable deprecation-sync warnings We currently disable deprecation synchronization warnings in case we're building with Clang. We check for Clang by doing a string comparison on the compiler identification, but this seems to have been broken by an update in macOS' image as the compiler ID has changed to "AppleClang". Let's just unconditionally disable this warning on Unix platforms. We never add the deprecated attribute anyway, so the warning doesn't help us at all.
Patrick Steinhardt 3956679c 2020-04-03T20:08:02 cmake: remove policies The `CMAKE_MINIUM_REQUIRE()` function not only sets up the minimum required CMake version of a project, but it will also at the same time set the CMake policy version. In effect this means that all policies that have been introduced before the minimum CMake version will be enabled automatically. When updating our minimum required version ebabb88f2 (cmake: update minimum CMake version to v3.5.1, 2019-10-10), we didn't remove any of the policies we've been manually enabling. The newest CMake policy we've been enabling is CMP0054, which was introduced back in CMake v3.1. As a result, we can now just remove all manual calls to `CMAKE_POLICY()`.
Patrick Steinhardt 2e7d4579 2020-04-03T19:59:39 cmake: remove option to add profiling flags We currently have an option that adds options for profiling to both our CFLAGS and LDFLAGS. Having such flags behind various build options is not really sensible at all, since users should instead set up those flags via environment variables supported by CMake itself. Let's remove this option.
Philip Kelley 63f9fbee 2020-04-25T15:37:45 MSVC: Enable Control Flow Guard (CFG) This feature requires Visual Studio 2015 (MSVC_VERSION = 1900) or later. As the minimum required CMake version is currently less than 3.7, GREATER_EQUAL is not available to us and we must invert the result of the LESS operator.
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.
Edward Thomson 70062e28 2019-10-31T17:46:21 version: update the version number to v0.99 This commit also switches our SOVERSION to be "$MAJOR.$MINOR" instead of "$MINOR", only. This is in preparation of v1.0, where the previous scheme would've stopped working in an obvious way.
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 625a3a49 2019-11-27T12:29:34 trace: enable tracing by default Tracing is meant to be extremely low-impact when not enabled. We currently ship no tracing calls in libgit2, but if / when we do, the tracing infrastructure is created to skip tracing as quickly as possible. It should compile to a simple test when tracing is off. Thus, there's on reason to not enable it by default.
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
Tobias Nießen 071750a3 2019-08-15T14:18:26 cmake: move _WIN32_WINNT definitions to root
Patrick Steinhardt d827b11b 2019-06-28T13:20:54 tests: execute leak checker via CTest directly Right now, we have an awful hack in our test CI setup that extracts the test command from CTest's output and then prepends the leak checker. This is dependent on non-machine-parseable output from CMake and also breaks on various ocassions, like for example when we have spaces in the current path or when the path contains backslashes. Both conditions may easily be triggered on Win32 systems, and in fact they do break our Azure Pipelines builds. Remove the awful hack in favour of a new CMake build option "USE_LEAK_CHECKER". If specifying e.g. "-DUSE_LEAK_CHECKER=valgrind", then we will set up all tests to be run under valgrind. Like this, we can again simply execute ctest without needing to rely on evil sourcery.
Edward Thomson e61b92e0 2019-06-24T15:22:39 clang: disable documentation-deprecated-sync Add the `-Wno-documentation-deprecated-sync` switch when compiling with clang, since our documentation adds `deprecated` markers, but we do not add the deprecation attribute in the code itself. (ie, the code is out of sync with the docs). In fact, we do not _want_ to mark these items as deprecated in the code, at least not yet, as we are not quite ready to bother our end-users with this since they're not going away.
Edward Thomson 54a60ced 2019-06-15T21:45:26 mingw: disable format specification warnings MinGW uses gcc, which expects POSIX formatting for printf, but uses the Windows C library, which uses its own format specifiers. Therefore, it gets confused about format specifiers. Disable warnings for format specifiers.
Patrick Steinhardt 393fb8a1 2019-06-17T12:15:19 cmake: default NTLM client to off if no HTTPS support If building libgit2 with `-DUSE_HTTPS=NO`, then CMake will generate an error complaining that there's no usable HTTPS backend for NTLM. In fact, it doesn't make sense to support NTLM when we don't support HTTPS. So let's should just have NTLM default to OFF when HTTPS is disabled to make life easier and to fix our OSSFuzz builds failing.
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 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.
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 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 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.
Edward Thomson 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.
Edward Thomson 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.
Edward Thomson 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.
Edward Thomson 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.
Edward Thomson 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.
Etienne Samson 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
Patrick Steinhardt 487233fa 2018-11-29T07:21:41 Merge pull request #4895 from pks-t/pks/unused-warnings Unused function warnings
Edward Thomson 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.
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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Edward Thomson 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Edward Thomson 1621a37d 2018-09-29T13:22:59 Merge pull request #4812 from libgit2/ethomson/ci-refactor CI: refactoring
Carlos Martín Nieto 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.
Edward Thomson 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.
Edward Thomson 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.
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 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.
Patrick Steinhardt ad0cb297 2018-07-20T12:17:42 cmake: fix the unholy options alignment mess
Patrick Steinhardt 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.
Patrick Steinhardt 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.
lhchavez 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.
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 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 6c6be3ce 2018-03-29T22:13:59 mbedtls: use libmbedcrypto for hashing
Jacques Germishuys e666495b 2018-03-08T08:31:49 cmake: enable shift count overflow warning
Patrick Steinhardt 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.
Edward Thomson f8a2dda8 2018-02-05T15:21:37 cmake: move ENABLE_WARNINGS to a module
Edward Thomson 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.
Edward Thomson ed298c8e 2018-02-02T18:01:51 cmake: move nanosecond detection to a module Move the nanosecond detection in time structures to its own module.
Edward Thomson 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.
Edward Thomson 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.
Carlos Martín Nieto 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.
Carlos Martín Nieto 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
Carlos Martín Nieto 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.
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 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.
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 10b25dbf 2017-08-10T00:03:30 cmake: braces are not needed here
Etienne Samson fdd06874 2017-08-09T21:35:53 cmake: use FeatureSummary to display which features we end up using
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}`.
Michael Haggerty 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.
Edward Thomson 8ac8c78c 2017-10-09T15:15:08 Merge pull request #4356 from pks-t/pks/static-clar cmake: use static dependencies when building static libgit2
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Edward Thomson 524c1d3c 2017-09-20T07:48:19 Merge pull request #4334 from pks-t/pks/reproducible-builds Reproducible builds
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
kmx.io     mail     discord kmxgit v0.4.0