1. 12 Oct, 2018 1 commit
    • tests: simplify cmake test configuration · 373bf31f
      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.
      
      (cherry picked from commit ce798b25)
      Edward Thomson committed
  2. 30 May, 2018 2 commits
  3. 03 Jan, 2018 4 commits
    • tests: create new test target for all SSH-based tests · 5874e151
      Some tests shall be run against our own SSH server we spin up in Travis.
      As those need to be run separate from our previous tests which run
      against git-daemon, we have to do this in a separate step. Instead of
      bundling all that knowledge in the CI script, move it into the test
      build instructions by creating a new test target.
      Patrick Steinhardt committed
    • tests: online::clone: inline creds-test with nonexistent URL · 54a1bf05
      Right now, we test our credential callback code twice, once via SSH on
      localhost and once via a non-existent GitHub repository. While the first
      URL makes sense to be configurable, it does not make sense to hard-code
      the non-existing repository, which requires us to call tests multiple
      times. Instead, we can just inline the URL into another set of tests.
      Patrick Steinhardt committed
    • tests: online::clone: construct credential-URL from environment · fea60920
      We support two types of passing credentials to the proxy, either via the
      URL or explicitly by specifying user and password. We test these types
      by modifying the proxy URL and executing the tests twice, which is
      in fact unnecessary and requires us to maintain the list of environment
      variables and test executions across multiple CI infrastructures.
      
      To fix the situation, we can just always pass the host, port, user and
      password to the tests. The tests can then assemble the complete URL
      either with or without included credentials, allowing us to test both
      cases in-process.
      Patrick Steinhardt committed
    • tests: perf: build but exclude performance tests by default · 543ec149
      Our performance tests (or to be more concrete, our single performance
      test) are not built by default, as they are always #ifdef'd out. While
      it is true that we don't want to run performance tests by default, not
      compiling them at all may cause code rot and is thus an unfavorable
      approach to handle this.
      
      We can easily improve this situation: this commit removes the #ifdef,
      causing the code to always be compiled. Furthermore, we add `-xperf` to
      the default command line parameters of `generate.py`, thus causing the
      tests to be excluded by default.
      
      Due to this approach, we are now able to execute the performance tests
      by passing `-sperf` to `libgit2_clar`. Unfortunately, we cannot execute
      the performance tests on Travis or AppVeyor as they rely on history
      being available for the libgit2 repository. As both do a shallow clone
      only, though, this is not given.
      Patrick Steinhardt committed
  4. 23 Oct, 2017 2 commits
  5. 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
  6. 20 Sep, 2017 2 commits
    • cmake: unify version check for target include directories · d8d2f21e
      There are two locations where we check whether CMake supports
      `TARGET_INCLUDE_DIRECTORIES`. While the first one uses `VERSION_LESS
      2.8.12`, the second one uses `VERSION_GREATER 2.8.11`, which are
      obviously equivalent to each other. It'd still be easier to grep for
      specific CMake versions being required for some features if both used
      the same conditional mentioning the actual target version required. So
      this commit refactors these conditions to make them equal.
      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
  7. 16 Aug, 2017 3 commits
    • 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: 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