1. 23 Feb, 2022 2 commits
  2. 14 Nov, 2021 1 commit
  3. 18 Oct, 2021 1 commit
  4. 06 Nov, 2019 1 commit
  5. 15 Feb, 2019 2 commits
    • examples: create common lg2 executable · ead10785
      Inside of our networking example code, we have a git2 executable
      that acts as an entry point to all the different network
      examples. As such, it is kind of the same like the normal git(1)
      executable in that it simply arbitrates to the respective
      subcommands.
      
      Let's extend this approach and merge all examples into a single
      standalone lg2 executable. Instead of building an executable
      for all the existing examples we have, we now bundle them all
      inside of the lg2 one and let them be callable via subcommands.
      
      In the process, we can get rid of duplicated library
      initialization, deinitialization and repository discovery code.
      Instead of having each subcommand handle these on its own, we
      simply do it inside of the single main function now.
      Patrick Steinhardt committed
    • examples: merge common network code · 7562422a
      Right now, we have two sets of "common" code, one containing
      general common code and one containing network common code. As we
      intend to get rid of the network subdirectory and instead merge
      all examples into a single standalone executable, this
      distinction doesn't make a lot of sense now. Furthermore, the
      common network code is not that big.
      
      Let's get rid of the common network code by merging it into the
      general common code.
      Patrick Steinhardt committed
  6. 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
  7. 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
  8. 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
  9. 25 Jan, 2018 1 commit
  10. 16 Aug, 2017 1 commit
    • 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
  11. 03 Mar, 2014 2 commits
  12. 30 Oct, 2013 1 commit
    • Extract common example helpers and reorg examples · 66902d47
      This reorganizes a few of the examples so that the main function
      comes first with the argument parsing extracted into a helper
      that can come at the end of the file (so the example focuses more
      on the use of libgit2 instead of command line support).  This also
      creates a shared examples/common.[ch] so that useful helper funcs
      can be shared across examples instead of repeated.
      Russell Belfer committed
  13. 03 Sep, 2013 1 commit