src/CMakeLists.txt


Log

Author Commit Date CI Message
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.
staticfloat@gmail.com b89162af 2018-06-10T17:26:08 Link `mbedTLS` libraries in when `SHA1_BACKEND == "mbedTLS"`
staticfloat@gmail.com 90c6fb0f 2018-06-10T17:33:06 Fix typo in adding `hash_mbedtls.c` to `SRC_SHA1`
Etienne Samson 64a78a80 2018-05-25T09:28:52 mbedtls: don't require mbedtls from our pkgconfig file mbedTLS has no pkgconfig file, hence we can't require it. For now, pass its link flags as our own.
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.
Patrick Steinhardt 0f62e4c7 2018-04-27T10:38:49 cmake: resolve libraries found by pkg-config Libraries found by CMake modules are usually handled with their full path. This makes linking against those libraries a lot more robust when it comes to libraries in non-standard locations, as otherwise we might mix up libraries from different locations when link directories are given. One excemption are libraries found by PKG_CHECK_MODULES. Instead of returning libraries with their complete path, it will return the variable names as well as a set of link directories. In case where multiple sets of the same library are installed in different locations, this can lead the compiler to link against the wrong libraries in the end, when link directories of other dependencies are added. To fix this shortcoming, we need to manually resolve library paths returned by CMake against their respective library directories. This is an easy task to do with `FIND_LIBRARY`.
Etienne Samson 54554757 2018-03-29T22:14:14 cmake: make our preferred backend ordering consistent
Etienne Samson 382ed1e8 2018-03-29T22:14:09 mbedtls: load default CA certificates
Etienne Samson 6c6be3ce 2018-03-29T22:13:59 mbedtls: use libmbedcrypto for hashing
Etienne Samson ca3b2234 2018-03-29T22:13:56 mbedtls: initial support
Carlos Martín Nieto b21c5408 2018-01-08T12:33:07 cmake: add openssl to the private deps list when it's the TLS implementation 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 b85548ed 2018-01-08T12:30:50 cmake: treat LIBGIT2_PC_REQUIRES as a list 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.
Edward Thomson 70db57d4 2018-01-05T15:31:51 Merge pull request #4398 from pks-t/pks/generic-sha1 cmake: allow explicitly choosing SHA1 backend
Patrick Steinhardt 70aa6146 2017-12-05T08:48:31 cmake: allow explicitly choosing SHA1 backend 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 30455a56 2018-01-03T13:09:21 Merge pull request #4439 from tiennou/fix/4352 cmake: create a dummy file for Xcode
Etienne Samson 4969a672 2017-12-10T02:19:34 cmake: create a dummy file for Xcode Otherwise Xcode will happily not-link our git2 target, resulting in a "missing file" error when building eg. examples
Edward Thomson bbb213c1 2017-11-11T13:19:24 cmake: let USE_ICONV be optional on macOS 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.
Henry Kleynhans a0b0b808 2017-11-11T14:03:14 cmake: Allow user to select bundled zlib 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
Etienne Samson c9bb68c2 2017-09-07T00:41:54 cmake: move Darwin-specific block around This allows us to only link against CoreFoundation when using the SecureTransport backend
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 fdd06874 2017-08-09T21:35:53 cmake: use FeatureSummary to display which features we end up using
Etienne Samson 99d6ebb3 2017-09-06T22:01:50 cmake: make our macOS helpers more CMake-y
Etienne Samson e9369856 2017-03-21T00:25:15 stream: Gather streams to src/streams
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 0e709032 2017-10-09T10:55:02 cmake: fix linking in Xcode with object libraries only 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 8c19969a 2017-09-06T07:38:48 cmake: fix static linking for bundled deps 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 172a585f 2017-09-05T15:09:34 cmake: always use object library for git2internal 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 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 a3a35473 2017-08-17T08:38:47 cmake: fix output location of import libraries and DLLs 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 8a43161b 2017-07-05T12:18:17 cmake: always include our own headers first With c26ce7840 (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 c26ce7840 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 e5c9723d 2017-06-30T18:12:02 cmake: move library build instructions into subdirectory 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.