1. 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
  2. 11 Jul, 2019 1 commit
  3. 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
  4. 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
  5. 19 May, 2019 2 commits
  6. 07 Apr, 2019 1 commit
  7. 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
  8. 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
  9. 03 Aug, 2018 1 commit
  10. 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
  11. 11 Apr, 2018 1 commit
  12. 05 Feb, 2018 1 commit
  13. 03 Feb, 2018 2 commits
  14. 23 Oct, 2017 2 commits
  15. 01 May, 2015 1 commit
  16. 23 Apr, 2015 1 commit
  17. 05 Dec, 2014 1 commit
  18. 15 Aug, 2014 1 commit
  19. 19 Apr, 2014 1 commit
  20. 30 Jan, 2014 3 commits
  21. 02 Dec, 2013 1 commit
  22. 30 May, 2013 1 commit
  23. 15 May, 2013 2 commits
  24. 07 May, 2013 1 commit