1. 15 Jul, 2022 1 commit
  2. 23 Feb, 2022 5 commits
  3. 05 Jan, 2022 1 commit
  4. 23 Dec, 2021 1 commit
    • cmake: use PROJECT_SOURCE_DIR of CMAKE_SOURCE_DIR · c5cd71b2
      Also applies to *_BINARY_DIR.
      
      This effectively reverts 84083dcc,
      which broke all users of libgit2 that use it as a CMake subdirectory
      (via `add_subdirectory()`). This is because CMAKE_SOURCE_DIR refers
      to the root-most CMake directory, which in the case of
      `add_subdirectory()` is a parent project to libgit2 and thus the paths
      don't make any sense to the configuration files. Corollary,
      CMAKE_SOURCE_DIR only makes sense if the CMake project is always the
      root project - which can rarely be guaranteed.
      
      In all honesty, CMake should deprecate and eventually remove
      CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR. It's been the source of headaches
      and confusion for years, they're rarely useful over
      CMAKE_CURRENT_(SOURCE|BINARY)_DIR or PROJECT_(SOURCE|BINARY)_DIR,
      and they cause a lot of confusing configuration and source
      code layouts to boot.
      
      Any time they are used, they break `add_subdirectory()` almost 100% of
      the time, cause confusing error messages, and hide subtle bugs.
      Josh Junon committed
  5. 22 Nov, 2021 1 commit
  6. 17 Nov, 2021 1 commit
  7. 16 Nov, 2021 1 commit
  8. 15 Nov, 2021 1 commit
  9. 14 Nov, 2021 1 commit
  10. 11 Nov, 2021 2 commits
  11. 18 Oct, 2021 1 commit
  12. 17 Oct, 2021 1 commit
  13. 30 Aug, 2021 1 commit
  14. 14 Jul, 2021 1 commit
  15. 05 May, 2021 1 commit
  16. 24 Jan, 2020 2 commits
  17. 10 Oct, 2019 1 commit
    • cmake: update minimum CMake version to v3.5.1 · ebabb88f
      Back in commit cf9f3452 (cmake: bump minimum version to 2.8.11,
      2017-09-06), we have bumped the minimum CMake version to require at
      least v2.8.11. The main hold-backs back then were distributions like
      RHEL/CentOS as well as Ubuntu Trusty, which caused us to not target a
      more modern version. Nowadays, Ubuntu Trusty has been EOL'd and CentOS 6
      has CMake v3.6.1 available via the EPEL6 repository, and thus it seems
      fair to upgrade to a more recent version.
      
      Going through repology [1], one can see that all supported mainstream
      distributions do in fact have CMake 3 available. Going through the list,
      the minimum version that is supported by all mainstream distros is in
      fact v3.5.1:
      
      	- CentOS 6 via EPEL6: 3.6.1
      	- Debian Oldstable: 3.7.2
      	- Fedora 26: 3.8.2
      	- OpenMandriva 3.x: 3.5.1
      	- Slackware 14.2: 3.5.2
      	- Ubuntu 16.04: 3.5.1
      
      Consequentally, let's upgrade CMake to the minimum version of 3.5.1 and
      remove all the version CMake checks that aren't required anymore.
      
      [1]: https://repology.org/project/cmake/versions
      Patrick Steinhardt committed
  18. 17 Aug, 2019 1 commit
  19. 29 Jul, 2019 1 commit
  20. 25 Jul, 2019 1 commit
  21. 20 Jul, 2019 1 commit
    • tests: execute leak checker via CTest directly · d827b11b
      Right now, we have an awful hack in our test CI setup that extracts the
      test command from CTest's output and then prepends the leak checker.
      This is dependent on non-machine-parseable output from CMake and also
      breaks on various ocassions, like for example when we have spaces in the
      current path or when the path contains backslashes. Both conditions may
      easily be triggered on Win32 systems, and in fact they do break our
      Azure Pipelines builds.
      
      Remove the awful hack in favour of a new CMake build option
      "USE_LEAK_CHECKER". If specifying e.g. "-DUSE_LEAK_CHECKER=valgrind",
      then we will set up all tests to be run under valgrind. Like this, we
      can again simply execute ctest without needing to rely on evil sourcery.
      Patrick Steinhardt committed
  22. 10 Jun, 2019 1 commit
  23. 14 Feb, 2019 1 commit
    • 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
  24. 19 Jan, 2019 1 commit
  25. 11 Jan, 2019 1 commit
  26. 10 Sep, 2018 1 commit
  27. 06 Sep, 2018 1 commit
  28. 26 Jul, 2018 1 commit
    • tests: simplify cmake test configuration · ce798b25
      Simplify the names for the tests, removing the unnecessary
      "libgit2-clar" prefix.  Make "all" the new default test run, and include
      the online tests by default (since HTTPS should always be enabled).
      
      For the CI tests, create an offline-only test, then the various online
      tests.
      Edward Thomson committed
  29. 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
  30. 09 May, 2018 1 commit
    • 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
  31. 19 Apr, 2018 1 commit
  32. 03 Jan, 2018 2 commits