1. 17 Oct, 2018 1 commit
  2. 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
  3. 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
  4. 17 Sep, 2018 1 commit
  5. 10 Sep, 2018 1 commit
  6. 06 Sep, 2018 1 commit
  7. 24 Aug, 2018 1 commit
  8. 03 Aug, 2018 5 commits
  9. 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
  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. 08 Mar, 2018 1 commit
  13. 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
  14. 05 Feb, 2018 1 commit
  15. 03 Feb, 2018 4 commits
  16. 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
  17. 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
  18. 04 Jan, 2018 2 commits
    • 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
    • cmake: default to using SHA1DC · e7495ce6
      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
  19. 11 Nov, 2017 2 commits
    • cmake: let USE_ICONV be optional on macOS · bbb213c1
      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
    • cmake: Allow user to select bundled zlib · a0b0b808
      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
  20. 23 Oct, 2017 4 commits
  21. 20 Oct, 2017 1 commit
    • cmake: use project-relative binary and source directories · 4da74c83
      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
  22. 14 Oct, 2017 1 commit
  23. 22 Sep, 2017 1 commit
    • cmake: use static dependencies when building static libgit2 · 49551254
      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
  24. 20 Sep, 2017 1 commit
    • cmake: bump minimum version to 2.8.11 · cf9f3452
      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
  25. 15 Sep, 2017 2 commits
    • cmake: fix linker error with dbghelper library · 54214d61
      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
    • cmake: enable reproducible static linking · d630887b
      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
  26. 25 Aug, 2017 1 commit
    • cmake: add switch to build with -Werror · 175ab8e7
      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