- 10 Jan, 2018 1 commit
-
-
When we print features, we make an effort to support all the way back to pre-3.0. However, in the code for versions from 3 onward we call `FEATURE_SUMMARY` with multiple kinds of elements to print in the same line. This is only supported in CMake 3.1 and later, making the rather popular CMake 3.0.2 unable to build the library. Use a single kind of element per invocation. This means we need to provide a "description" text, which CMake provides for us if provide multiple kinds of elements.
Carlos Martín Nieto committed
-
- 07 Jan, 2018 1 commit
-
-
If we're building static libraries, we want to use that for building our clar binary. This is done in 49551254 (2017-09-22; cmake: use static dependencies when building static libgit2) but that commit included the rule too early, making it affect the search for iconv, meaning we did not find it when we were building a static libgit2. Move the rule to just before building clar, after we've included the rules for building the library itself. This lets us find and link to the dynamic libiconv.
Carlos Martín Nieto committed
-
- 04 Jan, 2018 2 commits
-
-
Right now, if SHA1DC is disabled, the SHA1 backend is mostly chosen based on which system libgit2 is being compiled on and which libraries have been found. To give developers and distributions more choice, enable them to request specific backends by passing in a `-DSHA1_BACKEND=<BACKEND>` option instead. This completely replaces the previous auto-selection.
Patrick Steinhardt committed -
Upstream git.git has changed their default SHA1 implementation to the collision-detection algorithm SHA1DC in commit e6b07da27 (Makefile: make DC_SHA1 the default, 2017-03-17). To match upstream, align ourselves and switch over to SHA1DC by default.
Patrick Steinhardt committed
-
- 11 Nov, 2017 2 commits
-
-
Instead of forcing iconv support on macOS (by forcing `USE_ICONV` on), honor the `USE_ICONV` option only on macOS. Although macOS includes iconv by default, some macOS users may have a deficient installation for some reason and they should be provided a workaround to use libgit2 even in this situation. iconv support is now disabled entirely on non-macOS platforms. No other platform supports core.precomposeunicode, and iconv should never be linked.
Edward Thomson committed -
Under some circumstances the installed / system version of zlib may not be desirable due to being too old or buggy. This patch adds the option `USE_BUNDLED_ZLIB` that will cause the bundled version of zlib to be used. We may also want to add similar functionality to allow the user to select other bundled 3rd-party dependencies instead of using the system versions. /cc @pks-t @ethomson
Henry Kleynhans committed
-
- 23 Oct, 2017 4 commits
-
-
This allows us to only link against CoreFoundation when using the SecureTransport backend
Etienne Samson committed -
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 committed -
Etienne Samson committed
-
Etienne Samson committed
-
- 20 Oct, 2017 1 commit
-
-
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
-
- 14 Oct, 2017 1 commit
-
-
Apparently policy CMP0015 was added in CMake 3.1. With CMake 3.0.2, the build was failing with CMake Error at CMakeLists.txt:18 (CMAKE_POLICY): Policy "CMP0051" is not known to this version of CMake. This patch makes it work.
Michael Haggerty committed
-
- 22 Sep, 2017 1 commit
-
-
CMake allows us to build a static library by simply setting the variable `BUILD_SHARED_LIBS` to `OFF`. While this causes us to create a static libgit2.a archive, it will not automatically cause CMake to only locate static archives when searching for dependencies. This does no harm in case of building our libgit2.a, as we do not want to include all required dependencies in the resulting archive anyway. Instead, we ask users of a static libgit2.a to link against the required set of static archives themselves, typically aided by the libgit2.pc file. Where it does cause harm, though, is when we build the libgit2_clar test suite. CMake has happily populated our LIBGIT2_LIBS variable with shared libraries, and so linking the final libgit2_clar test does not do the right thing. It will simply ignore those shared libraries, we end up with a test suite with undefined symbols. To fix the issue, we can instruct CMake to only locate libraries with a certain suffix. As static libraries are typically identifiable by their ".a" suffix on Unix-based systems, we can instruct CMake to only locate libraries with this suffix to restrict it from finding any shared libraries. This fixes building a static libgit2_clar test suite. Note that this ignores the problem on Windows. The problem here is that we cannot even distinguish static and dynamic libraries by only inspecting their suffix. So we just ignore the problem on Windows, for now.
Patrick Steinhardt committed
-
- 20 Sep, 2017 1 commit
-
-
Our current minimum CMake version is 2.8. This version does not yet allow us to use object libraries (introduced in 2.8.8) and target include directories (introduced in 2.8.12), which are both mechanisms we want to use to fix some specific problems. We previously were not able to bump our CMake version to a version supporting object libraries because Ubuntu Precise only had CMake version 2.8.7 in its repositories. But due to Precise being end of life now, we shouldn't need to honor it anymore. A current survey of some of the more conservative distributions brings up the following versions of CMake: - CentOS 5: 2.6.2 - CentOS 6: 2.8.12.2 - Debian 7: 2.8.11 - Fedora 23: 3.3.2 - OpenSUSE 13.2: 3.0.2 - Ubuntu Precise: 2.8.7 - Ubuntu Trusty: 2.8.12 The only two outliers here are CentOS 5 and Ubuntu Precise. CentOS is currently unsupported due to our minimum version being 2.8 and Ubuntu Precise is not maintained anymore. So the next smallest version supported by all major distributions is 2.8.11. While this does not yet support target include directories, it at least enables us to use object libraries. So this becomes our new minimum required version.
Patrick Steinhardt committed
-
- 15 Sep, 2017 2 commits
-
-
When the MSVC_CRTDBG option is set by the developer, we will link in the dbghelper library to enable memory lead detection in MSVC projects. We are doing so by adding it to the variable `CMAKE_C_STANDARD_LIBRARIES`, so that it is linked for every library and executable built by CMake. But this causes our builds to fail with a linker error: ``` LINK: fatal error LNK1104: cannot open file 'advapi32.lib;Dbghelp.lib' ``` The issue here is that we are treating the variable as if it were an array of libraries by setting it via the following command: ``` SET(CMAKE_C_STANDARD_LIBRARIES "${CMAKE_C_STANDARD_LIBRARIES}" "Dbghelp.lib") ``` The generated build commands will then simply stringify the variable, concatenating all the contained libraries with a ";". This causes the observed linking failure. To fix the issue, we should just treat the variabable as a simple string. So instead of adding multiple members, we just add the "Dbghelp.lib" library to the existing string, separated by a space character.
Patrick Steinhardt committed -
By default, both ar(1) and ranlib(1) will insert additional information like timestamps into generated static archives and indices. As a consequence, generated static archives are not deterministic when created with default parameters. Both programs do support a deterministic mode, which will simply zero out undeterministic information with `ar D` and `ranlib -D`. Unfortunately, CMake does not provide an easy knob to add these command line parameters. Instead, we have to redefine the complete command definitons stored in the variables CMAKE_C_ARCHIVE_CREATE, CMAKE_C_ARCHIVE_APPEND and CMAKE_C_ARCHIVE_FINISH. Introduce a new build option `ENABLE_REPRODUCIBLE_BUILDS`. This option is available on Unix-like systems with the exception of macOS, which does not have support for the required flags. If the option is being enabled, we add those flags to the invocation of both `ar` and `ranlib` to enable deterministically building the static archive.
Patrick Steinhardt committed
-
- 25 Aug, 2017 2 commits
-
-
Add a simple switch to enable building with "-Werror=<warning>" instead of "-W<warning". Due to the encapsulated `ENABLE_WARNINGS` macro, this is as simple as adding a new variable "ENABLE_WERROR`, which can be passed on the command line via `-DENABLE_WERROR=ON`. The variable defaults to NO to not bother developers in their day to day work.
Patrick Steinhardt committed -
There are multiple sites where we enable or disable compiler warning via "-W<warning>" or "-Wno-<warning>". As we want to extend this mechanism later on to conditionally switch these over to "-Werror=<warning>", we encapsulate the logic into its their own macros `ENABLE_WARNINGS` and `DISABLE_WARNINGS`. Note that we in fact have to use a macro here. Using a function would not modify the CFLAGS inside of the callers scope, but in the function's scope only.
Patrick Steinhardt committed
-
- 16 Aug, 2017 19 commits
-
-
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 -
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 -
Extract code required to build the zlib library into its own CMakeLists.txt, which is included as required.
Patrick Steinhardt committed -
Extract code required to build the http-parser library into its own CMakeLists.txt, which is included as required.
Patrick Steinhardt committed -
Extract code required to build the regex library into its own CMakeLists.txt, which is included as required.
Patrick Steinhardt committed -
Extract code required to build the winhttp library into its own CMakeLists.txt, which is included as required.
Patrick Steinhardt committed -
This makes splitting up the library build instructions later on more obvious and easier to achieve.
Patrick Steinhardt committed -
This makes splitting up the library build instructions later on more obvious and easier to achieve.
Patrick Steinhardt committed -
This makes splitting up the library build instructions later on more obvious and easier to achieve.
Patrick Steinhardt committed -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
Currently, we're compiling our library code twice, once as part of the libgit2 library and once for the libgit2_clar executable. Since CMake 2.8.8, there exists a new library type OBJECT, which represents an intermediate target which can then subsequently be used when linking several targets against the same set of objects. Use an OBJECT library to create an internal library for linking. This new target is only used on CMake v2.8.8 or newer. As CMake 3.0 changed the way how generator expressions are evaluated when accessing properties, we need to enable CMake policy 0051 to keep `IDE_SPLIT_SOURCES` functioning.
Patrick Steinhardt committed -
Once upon a time, the `CLAR_RESOURCES` variable was intended to set the `CLAR_RESOURCES` define. But actually, the define uses a wrong variable name by accident, hinting that its value cannot actually be used at all, as it is empty. Searching through the code base confirms the guess that the define is not used at all. Remove both the variable and definition.
Patrick Steinhardt committed -
While we already make use of the variable `${CMAKE_THREAD_LIBS_INIT}`, it is actually undefined due to us never including the "FindThreads" module in the CMakeLists.txt. It is rather curious as to why this has never triggered any error up to now, but it does in fact result in linking errors on some Unix platforms as soon as we split up our build instructions into multiple files. Fix the issue now to avoid future breakage by including the "FindThreads" module.
Patrick Steinhardt committed
-
- 28 Jun, 2017 2 commits
-
-
Instead of using INCLUDE_DIRECTORIES again for the libgit2_clar test suite, we should just be using TARGET_INCLUDE_DIRECTORIES again if the CMake version is greater than 2.8.11.
Patrick Steinhardt committed -
Apply `target_include_directories` when CMAKE_VERSION >= 2.8.12
Andrey Davydov committed
-
- 23 Jun, 2017 1 commit
-
-
Change the output path of generate.py to generate the clar.suite file inside of the binary directory. This fixes out of tree builds with read-only source trees as we now refrain from writing anything into the source tree.
Patrick Steinhardt committed
-