1. 21 May, 2019 1 commit
  2. 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
  3. 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
  4. 25 Jan, 2019 2 commits
  5. 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
  6. 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
  7. 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
  8. 17 Oct, 2018 1 commit
  9. 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
  10. 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
  11. 17 Sep, 2018 1 commit
  12. 10 Sep, 2018 1 commit
  13. 06 Sep, 2018 1 commit
  14. 24 Aug, 2018 1 commit
  15. 03 Aug, 2018 5 commits
  16. 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
  17. 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
  18. 11 Apr, 2018 1 commit
  19. 08 Mar, 2018 1 commit
  20. 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
  21. 05 Feb, 2018 1 commit
  22. 03 Feb, 2018 4 commits
  23. 10 Jan, 2018 1 commit
    • cmake: use a FEATURE_SUMMARY call compatible with 3.0.2 · 6d452600
      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
  24. 07 Jan, 2018 1 commit
    • cmake: move the rule to find static archives close to building clar · 85e40bbf
      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
  25. 04 Jan, 2018 1 commit
    • cmake: allow explicitly choosing SHA1 backend · 70aa6146
      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