- 08 Jan, 2018 2 commits
-
-
We might want OpenSSL to be the implementation for SHA-1 and/or TLS. If we only want it for TLS (e.g. we're building with the collision-detecting SHA-1 implementation) then we did not indicate this to the systems including us a static library. Add OpenSSL to the list also during the TLS decision to make sure we say we should link to it if we use it for TLS.
Carlos Martín Nieto committed -
It is indeed a list of dependencies for those which include the static archive. This is in preparation for adding two possible places where we might add openssl as a dependency.
Carlos Martín Nieto committed
-
- 04 Jan, 2018 1 commit
-
-
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
-
- 14 Dec, 2017 1 commit
-
-
Otherwise Xcode will happily not-link our git2 target, resulting in a "missing file" error when building eg. examples
Etienne Samson 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 5 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
-
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
-
- 09 Oct, 2017 1 commit
-
-
CMake is unable to generate a correct Xcode project when trying to link libraries with only object libraries as its input. As our new build infrastructure makes heavy use of object libraries now, this affects our libgit2 library target, as well, leading to linking errors. Fix the issue by adding a dummy file to the libgit2 objects. As we always have the "features.h" header ready which contains defines only, we can simply link it into the resulting library without any effect whatsoever. This fixes building with Xcode.
Patrick Steinhardt committed
-
- 20 Sep, 2017 3 commits
-
-
Our bundled deps are being built as simple static libraries which are then linked into the libgit2 library via `TARGET_LINK_LIBRARIES`. While this works for a dynamically built libgit2 library, using this function to link two static libraries does not have the expected outcome of merging those static libraries into one big library. This leads to symbols of our bundled deps being undefined in the resulting libgit2 archive. As we have bumped our minimum CMake version to 2.8.11, we can now easily make use of object libraries for our bundled dependencies. So build instructions are still self-contained inside of the dependency directories and the resulting object libraries can just be added to the LIBGIT2_OBJECTS list, which will cause them to be linked into the final resulting static library. This fixes the issue of undefined symbols.
Patrick Steinhardt committed -
As we have bumped our minimum CMake version to 2.8.11, we can now unconditionally make use of object libraries. So remove the version check for the git2internal object library and always use it.
Patrick Steinhardt committed -
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
-
- 17 Aug, 2017 1 commit
-
-
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
-
- 16 Aug, 2017 20 commits
-
-
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 -
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
-