1. 24 Jun, 2019 2 commits
    • clang: disable documentation-deprecated-sync · e61b92e0
      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 committed
    • mingw: disable format specification warnings · 54a60ced
      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.
      Edward Thomson committed
  2. 17 Jun, 2019 1 commit
    • cmake: default NTLM client to off if no HTTPS support · 393fb8a1
      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.
      Patrick Steinhardt committed
  3. 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
  4. 13 Jun, 2019 1 commit
    • http-parser: use our bundled http-parser by default · fb529a01
      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 committed
  5. 10 Jun, 2019 1 commit
  6. 21 May, 2019 1 commit
  7. 19 May, 2019 2 commits
    • regex: optionally use PCRE2 · ce6d624a
      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 committed
    • regex: allow regex selection in cmake · c6e48fef
      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 committed
  8. 14 Feb, 2019 2 commits
    • deprecation: optionally enable hard deprecation · dcf81cdb
      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 committed
    • deprecation: ensure we GIT_EXTERN deprecated funcs · 24ac9e0c
      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 committed
  9. 25 Jan, 2019 2 commits
  10. 17 Jan, 2019 2 commits
    • cmake: error when STDCALL is specified · 57b753a0
      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 committed
    • Use cdecl calling conventions on Win32 · a74dd39b
      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.
      Edward Thomson committed
  11. 10 Jan, 2019 1 commit
    • cmake: remove unconditional -Wno-deprecated-declaration on APPLE · 2cc66dd5
      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
      Etienne Samson committed
  12. 28 Nov, 2018 4 commits
    • CMake: disable deprecated documentation sync · 3a2e4836
      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 committed
    • http: remove cURL · 21142c5a
      We previously used cURL to support HTTP proxies.  Now that we've added
      this support natively, we can remove the curl dependency.
      Edward Thomson committed
    • cmake: enable warnings for unused const variables · ffe39bab
      Together with the warnings for unused warnings, we always had warnings
      for unused constant variables disabled since commit 823c0e9c (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 committed
    • cmake: enable warnings for unused functions · 681c58cf
      Ever since commit 823c0e9c (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.
      Patrick Steinhardt committed
  13. 17 Oct, 2018 1 commit
  14. 05 Oct, 2018 1 commit
    • cmake: explicitly enable int-conversion warnings · aa0ae59a
      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
  15. 04 Oct, 2018 2 commits
    • cmake: enable new quoted argument policy CMP0054 · 633584b5
      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
    • cmake: remove spaces between `IF` and `(` for policies · 04d3853f
      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
  16. 17 Sep, 2018 1 commit
  17. 10 Sep, 2018 1 commit
  18. 06 Sep, 2018 1 commit
  19. 24 Aug, 2018 1 commit
  20. 03 Aug, 2018 5 commits
  21. 13 Jul, 2018 1 commit
    • cmake: enforce C90 standard · e1a4a8eb
      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
  22. 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
  23. 11 Apr, 2018 1 commit
  24. 08 Mar, 2018 1 commit
  25. 16 Feb, 2018 1 commit
    • CMakeLists: increase strict aliasing level to 3 · 522f3e4b
      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
  26. 05 Feb, 2018 1 commit
  27. 03 Feb, 2018 1 commit