1. 28 Nov, 2018 1 commit
  2. 20 Oct, 2018 1 commit
    • cmake: increase WIN32_WINNT to Vista · b8bdffb5
      Increase the WIN32_WINNT level to 0x0600, which enables support for new
      APIs from Windows 6.0 (Vista).  We had previously set this to 0x0501,
      which was Windows XP.  Although we removed XP support many years ago,
      there was no need to update this level previously.  We're doing so now
      explicitly so that we can get support for the `CreateSymbolicLink` API.
      Edward Thomson committed
  3. 24 Aug, 2018 1 commit
  4. 13 Jul, 2018 2 commits
    • 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
    • cmake: distinguish internal and system include directories · c13e56f9
      While we want to enforce strict C90 mode, this may cause issues with
      system provided header files which are themselves not strictly
      conforming. E.g. if a system header has C++ style comments, a compiler
      in strict C90 mode would produce an error and abort the build. As the
      user most likely doesn't want to change the system header, this would
      completely break the build on such systems. One example of this is
      mbedtls, which provides such header files.
      
      The problem can be worked around by distinguishing between
      system-provided and project-provided include directories. When adding
      include directories via "-isystem" instead of "-I", the compiler will
      skip certain checks and print out less warnings. To use system includes,
      we can simply add the "SYSTEM" flag to CMake's `INCLUDE_DIRECTORIES` and
      `TARGET_INCLUDE_DIRECTORIES` functions. Note that we have to split the
      include directories into two variables because of this, as we definitely
      still want to check for all warnings produced by our own header files.
      Patrick Steinhardt committed
  5. 11 Jun, 2018 2 commits
  6. 25 May, 2018 1 commit
  7. 09 May, 2018 2 commits
    • cmake: remove now-useless LIBGIT2_LIBDIRS handling · 8ab470f5
      With the recent change of always resolving pkg-config libraries to their
      full path, we do not have to manage the LIBGIT2_LIBDIRS variable
      anymore. The only other remaining user of LIBGIT2_LIBDIRS is winhttp,
      which is a CMake-style library target and can thus be resolved by CMake
      automatically.
      
      Remove the variable to simplify our build system a bit.
      Patrick Steinhardt committed
    • 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
  8. 11 Apr, 2018 4 commits
  9. 08 Jan, 2018 2 commits
  10. 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
  11. 14 Dec, 2017 1 commit
  12. 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
  13. 23 Oct, 2017 5 commits
  14. 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
  15. 09 Oct, 2017 1 commit
    • cmake: fix linking in Xcode with object libraries only · 0e709032
      CMake is unable to generate a correct Xcode project when trying to link
      libraries with only object libraries as its input. As our new build
      infrastructure makes heavy use of object libraries now, this affects our
      libgit2 library target, as well, leading to linking errors.
      
      Fix the issue by adding a dummy file to the libgit2 objects. As we
      always have the "features.h" header ready which contains defines only,
      we can simply link it into the resulting library without any effect
      whatsoever. This fixes building with Xcode.
      Patrick Steinhardt committed
  16. 20 Sep, 2017 3 commits
    • cmake: fix static linking for bundled deps · 8c19969a
      Our bundled deps are being built as simple static libraries which are
      then linked into the libgit2 library via `TARGET_LINK_LIBRARIES`. While
      this works for a dynamically built libgit2 library, using this function
      to link two static libraries does not have the expected outcome of
      merging those static libraries into one big library. This leads to
      symbols of our bundled deps being undefined in the resulting libgit2
      archive.
      
      As we have bumped our minimum CMake version to 2.8.11, we can now easily
      make use of object libraries for our bundled dependencies. So build
      instructions are still self-contained inside of the dependency
      directories and the resulting object libraries can just be added to the
      LIBGIT2_OBJECTS list, which will cause them to be linked into the final
      resulting static library. This fixes the issue of undefined symbols.
      Patrick Steinhardt committed
    • cmake: always use object library for git2internal · 172a585f
      As we have bumped our minimum CMake version to 2.8.11, we can now
      unconditionally make use of object libraries. So remove the version
      check for the git2internal object library and always use it.
      Patrick Steinhardt committed
    • cmake: distinguish libgit2 objects and sources · 1d9dd882
      Distinguish variables keeping track of our internal libgit2 sources and
      the final objects which shall be linked into the library. This will ease
      the transition to use object libraries for our bundled dependencies
      instead of linking them in.
      Patrick Steinhardt committed
  17. 17 Aug, 2017 1 commit
    • cmake: fix output location of import libraries and DLLs · a3a35473
      As observed by Edward Thomson, the libgit2 DLL built by Windows will not
      end up in the top-level build directory but instead inside of the 'src/'
      subdirectory. While confusing at first because we are actually setting
      the LIBRARY_OUTPUT_DIRECTORY to the project's binary directory, the
      manual page of LIBRARY_OUTPUT_DIRECTORY clears this up:
      
          There are three kinds of target files that may be built: archive,
          library, and runtime. Executables are always treated as runtime
          targets. Static libraries are always treated as archive targets.
          Module libraries are always treated as library targets. For non-DLL
          platforms shared libraries are treated as library targets. For DLL
          platforms the DLL part of a shared library is treated as a runtime
          target and the corresponding import library is treated as an archive
          target. All Windows-based systems including Cygwin are DLL
          platforms.
      
      So in fact, DLLs and import libraries are not treated as libraries at
      all by CMake but instead as runtime and archive targets. To fix the
      issue, we can thus simply set the variables RUNTIME_OUTPUT_DIRECTORY and
      ARCHIVE_OUTPUT_DIRECTORY to the project's root binary directory.
      Patrick Steinhardt committed
  18. 16 Aug, 2017 9 commits