- 17 Oct, 2018 1 commit
-
-
We use libssh2. We do not use libssh. Make sure to disambiguate them correctly.
Edward Thomson committed
-
- 05 Oct, 2018 1 commit
-
-
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 committed
-
- 04 Oct, 2018 2 commits
-
-
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 committed -
Our CMake coding style dictates that there should be no space between `IF` and its opening `(`. Adjust our policy statements to honor this style.
Patrick Steinhardt committed
-
- 17 Sep, 2018 1 commit
-
-
We do not currently have any warnings in this regard, but it's good practice to have them on in case we introduce something.
Carlos Martín Nieto committed
-
- 10 Sep, 2018 1 commit
-
-
This reverts commit a2d73f56. Using clar to propagate the XML settings was a mistake.
Edward Thomson committed
-
- 06 Sep, 2018 1 commit
-
-
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.
Edward Thomson committed
-
- 24 Aug, 2018 1 commit
-
-
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.
Etienne Samson committed
-
- 03 Aug, 2018 5 commits
-
-
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 committed -
Patrick Steinhardt committed
-
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 committed -
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.
Patrick Steinhardt committed -
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.
lhchavez committed
-
- 13 Jul, 2018 1 commit
-
-
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 committed
-
- 09 May, 2018 1 commit
-
-
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`.
Patrick Steinhardt committed
-
- 11 Apr, 2018 1 commit
-
-
Etienne Samson committed
-
- 08 Mar, 2018 1 commit
-
-
Jacques Germishuys committed
-
- 16 Feb, 2018 1 commit
-
-
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.
Patrick Steinhardt committed
-
- 05 Feb, 2018 1 commit
-
-
Edward Thomson committed
-
- 03 Feb, 2018 4 commits
-
-
Move the odd code that provides a hierarchical display for projects within the IDEs to its own module.
Edward Thomson committed -
Move the nanosecond detection in time structures to its own module.
Edward Thomson committed -
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 committed -
We can use policy checks to see if a policy exists in cmake, like CMP0051, instead of relying on the version.
Edward Thomson committed
-
- 10 Jan, 2018 1 commit
-
-
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 committed
-
- 07 Jan, 2018 1 commit
-
-
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.
Carlos Martín Nieto committed
-
- 04 Jan, 2018 2 commits
-
-
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 committed -
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.
Patrick Steinhardt committed
-
- 11 Nov, 2017 2 commits
-
-
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.
Edward Thomson committed -
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
Henry Kleynhans committed
-
- 23 Oct, 2017 4 commits
-
-
This allows us to only link against CoreFoundation when using the SecureTransport backend
Etienne Samson committed -
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 committed -
Etienne Samson committed
-
Etienne Samson committed
-
- 20 Oct, 2017 1 commit
-
-
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 committed
-
- 14 Oct, 2017 1 commit
-
-
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.
Michael Haggerty committed
-
- 22 Sep, 2017 1 commit
-
-
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 committed
-
- 20 Sep, 2017 1 commit
-
-
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.
Patrick Steinhardt committed
-
- 15 Sep, 2017 2 commits
-
-
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 committed -
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 committed
-
- 25 Aug, 2017 1 commit
-
-
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 committed
-