1. 15 Sep, 2017 1 commit
    • diff: cleanup hash ctx in `git_diff_patchid` · 046b081a
      After initializing the hash context in `git_diff_patchid`, we never
      proceed to call `git_hash_ctx_cleanup` on it. While this doesn't really
      matter on most hash implementations, this causes a memory leak on Win32
      due to CNG system requiring a `malloc` call.
      
      Fix the memory leak by always calling `git_hash_ctx_cleanup` before
      exiting.
      Patrick Steinhardt committed
  2. 12 Sep, 2017 3 commits
  3. 11 Sep, 2017 1 commit
  4. 10 Sep, 2017 1 commit
  5. 09 Sep, 2017 1 commit
  6. 25 Aug, 2017 14 commits
  7. 24 Aug, 2017 1 commit
  8. 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
  9. 16 Aug, 2017 17 commits
    • cmake: always include our own headers first · 8a43161b
      With c26ce784 (Merge branch 'AndreyG/cmake/modernization', 2017-06-28),
      we have recently introduced a regression in the way we are searching for
      headers. We have made sure to always include our own headers first, but
      due to the changes in c26ce784  this is no longer guaranteed. In fact,
      this already leads the compiler into picking "config.h" from the
      "deps/regex" dependency, if it is used.
      
      Fix the issue by declaring our internal include directories up front,
      before any of the other search directories is added.
      Patrick Steinhardt committed
    • 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