tests/CMakeLists.txt


Log

Author Commit Date CI Message
Edward Thomson 5368be30 2021-05-05T23:01:57 clar: support long paths on Windows
Edward Thomson 7fd9b3f5 2020-01-01T20:48:15 ci: add NTLM tests Download poxygit, a debugging git server, and clone from it using NTLM, both IIS-style (with connection affinity) and Apache-style ("broken", requiring constant reauthentication).
Edward Thomson e5fb5fe5 2019-10-20T17:19:01 ci: perform SPNEGO tests Attempt to obtain a Kerberos ticket from LIBGIT2.ORG and then clone the Negotiate-protected site at test.libgit2.org with that ticket.
Patrick Steinhardt ebabb88f 2019-10-10T09:25:32 cmake: update minimum CMake version to v3.5.1 Back in commit cf9f34521 (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
Tobias Nießen 071750a3 2019-08-15T14:18:26 cmake: move _WIN32_WINNT definitions to root
Tobias Nießen 75cc755f 2019-07-29T18:05:35 cmake: fix _WIN32_WINNT for MinGW
Ian Hattendorf 42ea2f95 2019-07-25T13:15:10 clone: whitespace in url ssh test
Patrick Steinhardt d827b11b 2019-06-28T13:20:54 tests: execute leak checker via CTest directly 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.
Edward Thomson 7912db49 2019-03-14T10:35:03 ci: enable all proxy tests
Edward Thomson 24ac9e0c 2019-02-13T23:26:54 deprecation: ensure we GIT_EXTERN deprecated funcs 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 423d3e73 2019-01-19T00:08:05 ci: precisely identify the invasive tests
Etienne Samson 1b4ba844 2019-01-11T11:53:54 ci: enable some of the invasive testcases
Edward Thomson 943181c2 2018-09-10T12:36:51 Revert "clar: introduce CLAR_XML option" This reverts commit a2d73f5643814cddf90d5bf489332e14ada89ab8. Using clar to propagate the XML settings was a mistake.
Edward Thomson a2d73f56 2018-08-24T11:23:19 clar: introduce CLAR_XML option Introduce a CLAR_XML option, to run the `ctest` commands with the new `-r` flag to clar. Permitted values are `OFF`, `ON` and a directory to write the XML test results to.
Edward Thomson ce798b25 2018-07-04T10:56:56 tests: simplify cmake test configuration 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.
Patrick Steinhardt e1a4a8eb 2018-06-25T11:58:34 cmake: enforce C90 standard 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 c13e56f9 2018-06-25T14:12:53 cmake: distinguish internal and system include directories 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 8ab470f5 2018-04-27T15:31:43 cmake: remove now-useless LIBGIT2_LIBDIRS handling 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.
Andreas Baumann fac7eac4 2018-04-19T15:21:52 fixed stack smashing due to wrong size of struct stat on the stack on 32-bit systems with 64-bit file descriptor offsets enabled (added -D_FILE_OFFSET_BITS=64 when compiling the test suite)
Patrick Steinhardt 5874e151 2017-11-20T13:26:33 tests: create new test target for all SSH-based tests 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 54a1bf05 2017-06-07T13:06:53 tests: online::clone: inline creds-test with nonexistent URL 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 fea60920 2017-06-07T12:48:48 tests: online::clone: construct credential-URL from environment 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 543ec149 2017-06-07T11:06:01 tests: perf: build but exclude performance tests by default 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.
Etienne Samson 9980be03 2017-09-06T22:13:58 cmake: Add USE_HTTPS as a CMake option It defaults to ON, e.g. "pick whatever default is appropriate for the platform". It accepts one of SecureTransport, OpenSSL, WinHTTP, or OFF. It errors if the backend library couldn't be found.
Etienne Samson 08c1b8fc 2017-08-28T21:24:13 cmake: simplify some HTTPS tests
Patrick Steinhardt 4da74c83 2017-10-20T07:29:17 cmake: use project-relative binary and source directories 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 d8d2f21e 2017-09-06T07:52:12 cmake: unify version check for target include directories 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 1d9dd882 2017-09-05T15:06:29 cmake: distinguish libgit2 objects and sources 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 8e31cc25 2017-06-28T12:51:14 cmake: keep track of libraries and includes via lists 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 a390a846 2017-07-01T13:06:00 cmake: move defines into "features.h" header 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 35087f0e 2017-06-28T15:42:54 cmake: create separate CMakeLists.txt for tests 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.