1. 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
  2. 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
  3. 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
  4. 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
  5. 23 Oct, 2017 4 commits
  6. 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
  7. 14 Oct, 2017 1 commit
  8. 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
  9. 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
  10. 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
  11. 25 Aug, 2017 2 commits
    • 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
    • cmake: encapsulate enabling/disabling compiler warnings · 4a46a8c1
      There are multiple sites where we enable or disable compiler warning via
      "-W<warning>" or "-Wno-<warning>". As we want to extend this mechanism
      later on to conditionally switch these over to "-Werror=<warning>", we
      encapsulate the logic into its their own macros `ENABLE_WARNINGS` and
      `DISABLE_WARNINGS`.
      
      Note that we in fact have to use a macro here. Using a function would
      not modify the CFLAGS inside of the callers scope, but in the function's
      scope only.
      Patrick Steinhardt committed
  12. 16 Aug, 2017 19 commits
    • cmake: move library build instructions into subdirectory · e5c9723d
      To fix leaking build instructions into different targets and to make
      the build instructions easier to handle, create a new CMakeLists.txt
      file containing build instructions for the libgit2 target.
      
      By now, the split is rather easy to achieve. Due to the preparatory
      steps, we can now simply move over all related build instructions, only
      needing to remove the "src/" prefix from some files.
      Patrick Steinhardt committed
    • cmake: fix up source and binary directory paths · 72f27cb6
      There are quite some uses of the variables "${CMAKE_CURRENT_SOURCE_DIR}"
      and "${CMAKE_CURRENT_BINARY_DIR}" where they are not appropriate.
      Convert these sites to instead use the variables "${CMAKE_SOURCE_DIR}"
      and "${CMAKE_BINARY_DIR}", which instead point to the project's root
      directory.
      
      This will ease splitting up the library build instructions into its own
      subdirectory.
      Patrick Steinhardt committed
    • cmake: move zlib build instructions into subdirectory · 1f43a43d
      Extract code required to build the zlib library into its own
      CMakeLists.txt, which is included as required.
      Patrick Steinhardt committed
    • cmake: move http-parser build instructions into subdirectory · b7514554
      Extract code required to build the http-parser library into its own
      CMakeLists.txt, which is included as required.
      Patrick Steinhardt committed
    • cmake: move regex build instructions into subdirectory · 9e449e52
      Extract code required to build the regex library into its own
      CMakeLists.txt, which is included as required.
      Patrick Steinhardt committed
    • cmake: move winhttp build instructions into subdirectory · 43248500
      Extract code required to build the winhttp library into its own
      CMakeLists.txt, which is included as required.
      Patrick Steinhardt committed
    • cmake: define WIN_RC with other platform sources · bed7ca3a
      This makes splitting up the library build instructions later on more
      obvious and easier to achieve.
      Patrick Steinhardt committed
    • cmake: find dependencies after setting build flags · 8ee90c39
      This makes splitting up the library build instructions later on more
      obvious and easier to achieve.
      Patrick Steinhardt committed
    • cmake: move definition of Win32 flags together · c3635130
      This makes splitting up the library build instructions later on more
      obvious and easier to achieve.
      Patrick Steinhardt committed
    • cmake: inline TARGET_OS_LIBRARIES function · 32a2e500
      Previous to keeping track of libraries and linking directories via
      variables, we had two call sites of the `TARGET_OS_LIBRARIES` function
      to avoid duplicating knowledge on required operating system library
      dependencies. But as the libgit2_clar target now re-uses defined
      variables to link against these libraries, we can simply inline the
      function.
      Patrick Steinhardt committed
    • cmake: keep track of libraries and includes via lists · 8e31cc25
      Later on, we will move detection of required libraries, library
      directories as well as include directories into a separate
      CMakeLists.txt file inside of the source directory. Obviously, we want
      to avoid duplication here regarding these parameters.
      
      To prepare for the split, put the parameters into three variables
      LIBGIT2_LIBS, LIBGIT2_LIBDIRS and LIBGIT2_INCLUDES, tracking the
      required libraries, linking directory as well as include directories.
      These variables can later be exported into the parent scope from inside
      of the source build instructions, making them readily available for the
      other subdirectories.
      Patrick Steinhardt committed
    • cmake: use absolute path to deps · dd332e2a
      When refering to files and directories inside of the top-level "deps/"
      directory, we're being inconsistent in using relative or absolute paths.
      To enable splitting out parts of the top-level CMakeLists.txt into an
      own file in the "src/" directory, consistently switch over to use
      absolute paths to avoid errors when converting.
      Patrick Steinhardt committed
    • cmake: move regcomp and futimens checks to "features.h" · 8341d6cf
      In our CMakeLists.txt, we have to check multiple functions in order to
      determine if we have to use our own or whether we can use the
      platform-provided one. For two of these functions, namely `regcomp_l()`
      and `futimens`, the defined macro is actually used inside of the header
      file "src/unix/posix.h". As such, these macros are not only required by
      the library, but also by our test suite, which is makes use of internal
      headers.
      
      To prepare for the CMakeLists.txt split, move these two defines inside
      of the "features.h" header.
      Patrick Steinhardt committed
    • cmake: move defines into "features.h" header · a390a846
      In a future commit, we will split out the build instructions for our
      library directory and move them into a subdirectory. One of the benefits
      is fixing scoping issues, where e.g. defines do not leak to build
      targets where they do not belong to. But unfortunately, this does also
      pose the problem of how to propagate some defines which are required by
      both the library and the test suite.
      
      One way would be to create another variable keeping track of all added
      defines and declare it inside of the parent scope. While this is the
      most obvious and simplest way of going ahead, it is kind of unfortunate.
      The main reason to not use this is that these defines become implicit
      dependencies between the build targets. By simply observing a define
      inside of the CMakeLists.txt file, one cannot reason whether this define
      is only required by the current target or whether it is required by
      different targets, as well.
      
      Another approach would be to use an internal header file keeping track
      of all defines shared between targets. While configuring the library, we
      will set various variables and let CMake configure the file, adding or
      removing defines based on what has been configured. Like this, one can
      easily keep track of the current environment by simply inspecting the
      header file. Furthermore, these dependencies are becoming clear inside
      the CMakeLists.txt, as instead of simply adding a define, we now call
      e.g. `SET(GIT_THREADSAFE 1)`.
      
      Having this header file though requires us to make sure it is always
      included before any "#ifdef"-preprocessor checks are executed. As we
      have already refactored code to always include the "common.h" header
      file before any statement inside of a file, this becomes easy: just make
      sure "common.h" includes the new "features.h" header file first.
      Patrick Steinhardt committed
    • cmake: create separate CMakeLists.txt for tests · 35087f0e
      Our CMakeLists.txt is very unwieldy in its current size, spanning more
      than 700 lines of code. Furthermore, it has several issues regarding
      scoping, where for example some defines, includes, etc. from our test
      suite are also applied to our normal library code.
      
      To fix this, we can separate out build instructions for our tests and
      move them into their own CMakeLists.txt in the "tests" directory. This
      reduced complexity of the root CMakeLists.txt file and fixes the issues
      regarding leaking build context from tests into the library.
      Patrick Steinhardt committed
    • cmake: create own precompiled headers for tests · 3267115f
      As soon as we split up our CMakeBuild.txt build instructions, we will be
      unable to simply link against the git2 library's precompiled header from
      other targets. To avoid this future breakage, create a new precompiled
      header for our test suite. Next to being compatible with the split, this
      enables us to also include additional files like the clar headers, which
      may help speeding up compilation of the test suite.
      Patrick Steinhardt committed
    • cmake: create object library target · caab8270
      Currently, we're compiling our library code twice, once as part of the
      libgit2 library and once for the libgit2_clar executable. Since CMake
      2.8.8, there exists a new library type OBJECT, which represents an
      intermediate target which can then subsequently be used when linking
      several targets against the same set of objects.
      
      Use an OBJECT library to create an internal library for linking. This
      new target is only used on CMake v2.8.8 or newer. As CMake 3.0 changed
      the way how generator expressions are evaluated when accessing
      properties, we need to enable CMake policy 0051 to keep
      `IDE_SPLIT_SOURCES` functioning.
      Patrick Steinhardt committed
    • cmake: remove unused variable "CLAR_RESOURCES" · f33911e5
      Once upon a time, the `CLAR_RESOURCES` variable was intended to set
      the `CLAR_RESOURCES` define. But actually, the define uses a wrong
      variable name by accident, hinting that its value cannot actually be
      used at all, as it is empty. Searching through the code base confirms
      the guess that the define is not used at all.
      
      Remove both the variable and definition.
      Patrick Steinhardt committed
    • cmake: try to detect threads library · 096a49c0
      While we already make use of the variable `${CMAKE_THREAD_LIBS_INIT}`,
      it is actually undefined due to us never including the "FindThreads"
      module in the CMakeLists.txt. It is rather curious as to why this has
      never triggered any error up to now, but it does in fact result in
      linking errors on some Unix platforms as soon as we split up our build
      instructions into multiple files.
      
      Fix the issue now to avoid future breakage by including the
      "FindThreads" module.
      Patrick Steinhardt committed
  13. 28 Jun, 2017 2 commits
  14. 23 Jun, 2017 1 commit