1. 12 Jul, 2020 1 commit
    • cmake: remove CheckPrototypeDefinition module · 9bc6e655
      In the past, we've imported the CheckPrototypeDefinition into our own
      module directory as it wasn't yet available in all supported CMake
      versions. Now that we require at least CMake v3.5, we don't need to
      bundle it anymore as it's included with the distribution already.
      
      Let's drop the included modules and always use upstream's version.
      Patrick Steinhardt committed
  2. 01 Jun, 2020 1 commit
  3. 15 May, 2020 1 commit
    • cmake: Sort source files for reproducible builds · b85eefb4
      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.
      Patrick Steinhardt committed
  4. 01 Apr, 2020 1 commit
  5. 14 Mar, 2020 1 commit
    • cmake: use install directories provided via GNUInstallDirs · 87fc539f
      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 committed
  6. 24 Feb, 2020 1 commit
    • cmake: sanitize boolean options passed by user · 41b6d30c
      Starting with our conversions to mix backend-autodetection and selection
      into a single variable (USE_GSSAPI, USE_HTTPS, USE_SHA1), we have
      introduced a simple STREQUAL to check for "ON", which indicates that the
      user wants us to auto-detect available backends and pick any one that's
      available. This behaviour deviates from previous behaviour, as passing a
      value like "yes", "on" or "true" will in fact be treated like a backend
      name and result in autodetection failure.
      
      Fix the issue by introducing a new function `SanitizeBool`. Given a
      variable that may hold a boolean value, the function will sanitize that
      variable to hold either "ON" or "OFF". In case it is not a recognized
      boolean, we will just keep the value as-is. This fixes the above
      described issue.
      Patrick Steinhardt committed
  7. 19 Feb, 2020 1 commit
  8. 24 Jan, 2020 1 commit
  9. 13 Oct, 2019 2 commits
  10. 21 Sep, 2019 1 commit
  11. 14 Sep, 2019 1 commit
  12. 13 Sep, 2019 2 commits
    • cmake: fix various misuses of MESSAGE() · 212b6f65
      The MESSAGE() function expects as first argument the message type, e.g.
      STATUS or FATAL_ERROR. In some places, we were misusing this to either
      not provide any type, which would then erroneously print the message to
      standard error, or to use FATAL instead of FATAL_ERROR.
      
      Fix all of these instances. Also, remove some MESSAGE invocations that
      are obvious leftovers from debugging the build system.
      Patrick Steinhardt committed
    • cmake: properly abort if no mbedTLS cert location is found · e77fdf87
      When using mbedTLS as backend, then the user may specify the location of
      where system certificates are installed. If no such location is provided
      by the user, CMake will try to autodetect the location by using the
      openssl executable, if installed. If no location could be detected, then
      the mbedTLS is essentially worthless as it is completely unable to
      verify any certificates.
      
      To avoid use of such misconfigured mbedTLS configurations, let's error
      out if we were unable to find out the location.
      Patrick Steinhardt committed
  13. 10 Sep, 2019 1 commit
  14. 18 Jul, 2019 1 commit
    • cmake: include SHA1 headers into our source files · b7c247b3
      When selecting the SHA1 backend, we only include the respective C
      implementation of the selected backend. But since commit bd48bf3f
      (hash: introduce source files to break include circles, 2019-06-14), we
      have introduced separate headers and compilation units for all hashes.
      So by not including the headers, we may not honor them to compute
      whether a file needs to be recompiled and they also will not be
      displayed in IDEs.
      
      Add the header files to fix this problem.
      Patrick Steinhardt committed
  15. 11 Jul, 2019 1 commit
  16. 24 Jun, 2019 3 commits
    • hash: move SHA1 implementations into 'sha1/' folder · fda20622
      As we will include additional hash algorithms in the future due
      to upstream git discussing a move away from SHA1, we should
      accomodate for that and prepare for the move. As a first step,
      move all SHA1 implementations into a common subdirectory.
      
      Also, create a SHA1-specific header file that lives inside the
      hash folder. This header will contain the SHA1-specific header
      includes, function declarations and the SHA1 context structure.
      Patrick Steinhardt committed
    • win32: support upgrading warnings to errors (/WX) · cc9e47c9
      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.
      Edward Thomson committed
    • hash: introduce source files to break include circles · bd48bf3f
      The hash source files have circular include dependencies right
      now, which shows by our broken generic hash implementation. The
      "hash.h" header declares two functions and the `git_hash_ctx`
      typedef before actually including the hash backend header and can
      only declare the remaining hash functions after the include due
      to possibly static function declarations inside of the
      implementation includes.
      
      Let's break this cycle and help maintainability by creating a
      real implementation file for each of the hash implementations.
      Instead of relying on the exact include order, we now especially
      avoid the use of `GIT_INLINE` for function declarations.
      Patrick Steinhardt committed
  17. 14 Jun, 2019 1 commit
    • cmake: Modulize our TLS & hash detection · 94fc83b6
      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.
      Etienne Samson committed
  18. 19 May, 2019 2 commits
  19. 07 Apr, 2019 1 commit
  20. 10 Jan, 2019 1 commit
    • Make ENABLE_WERROR actually work · 6af6170b
      This change explicitly adds -Werror to the CFLAGS.
      
      Due to the way that the ADD_C_FLAG_IF_SUPPORTED() macro was mangling the
      flag name to convert it into a define name, any warning that had a dash
      in its name was not being correctly enabled. Additionally, any flag that
      is enabled implicitly by the compiler (like -Wunused-result and
      -Wdeprecated-declarations) would not cause an error unless they were
      explicitly enabled with the ENABLE_WARNINGS() macro.
      lhchavez committed
  21. 24 Aug, 2018 2 commits
    • util: make the qsort_r check work on macOS · 1a9cc182
      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
    • cmake: detect and use libc-provided iconv · 2e2d8c64
      While most systems provide a separate iconv library against which
      applications can link, musl based systems do not provide such a library.
      Instead, iconv functions are directly included in the C library. As our
      current CMake module to locate the iconv library only checks whether a
      library exists somewhere in the typical library directories, we will
      never build libgit2 with libiconv support on such systems.
      
      Extend the iconv module to also search whether libc provides iconv
      functions, which we do by checking whether the `iconv_open` function
      exists inside of libc. If this is the case, we will default to use the
      libc provided one instead of trying to use a separate libiconv. While
      this changes which iconv we use on systems where both libc and an
      external libiconv exist, to the best of my knowledge common systems only
      provide either one or the other.
      
      Note that libiconv support in musl is held kind of basic. To quote musl
      libc's page on functional differences from glibc [1]:
      
          The iconv implementation musl is very small and oriented towards
          being unobtrusive to static link. Its character set/encoding
          coverage is very strong for its size, but not comprehensive like
          glibc’s.
      
      As we assume iconv to be a lot more capable than what musl provides,
      some of our tests will fail if using iconv on musl-based platforms.
      
      [1]: https://wiki.musl-libc.org/functional-differences-from-glibc.html
      Patrick Steinhardt committed
  22. 03 Aug, 2018 1 commit
  23. 09 May, 2018 1 commit
    • cmake: resolve libraries found by pkg-config · 0f62e4c7
      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
  24. 11 Apr, 2018 1 commit
  25. 05 Feb, 2018 1 commit
  26. 03 Feb, 2018 2 commits
  27. 23 Oct, 2017 2 commits
  28. 01 May, 2015 1 commit
  29. 23 Apr, 2015 1 commit
  30. 05 Dec, 2014 1 commit
  31. 15 Aug, 2014 1 commit
  32. 19 Apr, 2014 1 commit