summaryrefslogtreecommitdiff
path: root/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
* cmake: always disable deprecation-sync warningsPatrick Steinhardt2020-06-011-20/+17
| | | | | | | | | | We currently disable deprecation synchronization warnings in case we're building with Clang. We check for Clang by doing a string comparison on the compiler identification, but this seems to have been broken by an update in macOS' image as the compiler ID has changed to "AppleClang". Let's just unconditionally disable this warning on Unix platforms. We never add the deprecated attribute anyway, so the warning doesn't help us at all.
* cmake: remove policiesPatrick Steinhardt2020-06-011-11/+2
| | | | | | | | | | | | | | The `CMAKE_MINIUM_REQUIRE()` function not only sets up the minimum required CMake version of a project, but it will also at the same time set the CMake policy version. In effect this means that all policies that have been introduced before the minimum CMake version will be enabled automatically. When updating our minimum required version ebabb88f2 (cmake: update minimum CMake version to v3.5.1, 2019-10-10), we didn't remove any of the policies we've been manually enabling. The newest CMake policy we've been enabling is CMP0054, which was introduced back in CMake v3.1. As a result, we can now just remove all manual calls to `CMAKE_POLICY()`.
* cmake: remove option to add profiling flagsPatrick Steinhardt2020-06-011-6/+0
| | | | | | | | | We currently have an option that adds options for profiling to both our CFLAGS and LDFLAGS. Having such flags behind various build options is not really sensible at all, since users should instead set up those flags via environment variables supported by CMake itself. Let's remove this option.
* cmake: remove support for creating tagsPatrick Steinhardt2020-06-011-20/+0
| | | | | | | | | | | | We currently have support for generating tags via ctags as part of our build system. We aren't really in the place of supporting any tooling that exists apart from the actual build environment, as doing so adds additional complexity and maintenance burden to our build instructions. This is in fact nicely demonstrated by this particular option, as it hasn't been working anymore since commit e5c9723d0 (cmake: move library build instructions into subdirectory, 2017-06-30). As a result, this commit removes support for building CTags
* cmake: move modules into the "cmake/" top level dirPatrick Steinhardt2020-06-011-1/+1
| | | | | | | | Our custom CMake module currently live in "cmake/Modules". As the "cmake/" directory doesn't contain anything except the "Modules" directory, it doesn't really make sense to have the additional intermediate directory. So let's instead move the modules one level up into the "cmake/" top level directory.
* MSVC: Enable Control Flow Guard (CFG)Philip Kelley2020-04-251-0/+10
| | | | | | This feature requires Visual Studio 2015 (MSVC_VERSION = 1900) or later. As the minimum required CMake version is currently less than 3.7, GREATER_EQUAL is not available to us and we must invert the result of the LESS operator.
* cmake: use install directories provided via GNUInstallDirsPatrick Steinhardt2020-03-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | We currently hand-code logic to configure where to install our artifacts via the `LIB_INSTALL_DIR`, `INCLUDE_INSTALL_DIR` and `BIN_INSTALL_DIR` variables. This is reinventing the wheel, as CMake already provide a way to do that via `CMAKE_INSTALL_<DIR>` paths, e.g. `CMAKE_INSTALL_LIB`. This requires users of libgit2 to know about the discrepancy and will require special hacks for any build systems that handle these variables in an automated way. One such example is Gentoo Linux, which sets up these paths in both the cmake and cmake-utils eclass. So let's stop doing that: the GNUInstallDirs module handles it in a better way for us, especially so as the actual values are dependent on CMAKE_INSTALL_PREFIX. This commit removes our own set of variables and instead refers users to use the standard ones. As a second benefit, this commit also fixes our pkgconfig generation to use the GNUInstallDirs module. We had a bug there where we ignored the CMAKE_INSTALL_PREFIX when configuring the libdir and includedir keys, so if libdir was set to "lib64", then libdir would be an invalid path. With GNUInstallDirs, we can now use `CMAKE_INSTALL_FULL_LIBDIR`, which handles the prefix for us.
* version: update the version number to v0.99Edward Thomson2020-02-191-2/+2
| | | | | | This commit also switches our SOVERSION to be "$MAJOR.$MINOR" instead of "$MINOR", only. This is in preparation of v1.0, where the previous scheme would've stopped working in an obvious way.
* cmake: consolidate Valgrind optionPatrick Steinhardt2020-02-111-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OpenSSL doesn't initialize bytes on purpose in order to generate additional entropy. Valgrind isn't too happy about that though, causing it to generate warninings about various issues regarding use of uninitialized bytes. We traditionally had some infrastructure to silence these errors in our OpenSSL stream implementation, where we invoke the Valgrind macro `VALGRIND_MAKE_MEMDEFINED` in various callbacks that we provide to OpenSSL. Naturally, we only include these instructions if a preprocessor define "VALGRIND" is set, and that in turn is only set if passing "-DVALGRIND" to CMake. We do that in our usual Azure pipelines, but we in fact forgot to do this in our nightly build. As a result, we get a slew of warnings for these nightly builds, but not for our normal builds. To fix this, we could just add "-DVALGRIND" to our nightly builds. But starting with commit d827b11b6 (tests: execute leak checker via CTest directly, 2019-06-28), we do have a secondary variable that directs whether we want to use memory sanitizers for our builds. As such, every user wishing to use Valgrind for our tests needs to pass both options "VALGRIND" and "USE_LEAK_CHECKER", which is cumbersome and error prone, as can be seen by our own builds. Instead, let's consolidate this into a single option, removing the old "-DVALGRIND" one. Instead, let's just add the preprocessor directive if USE_LEAK_CHECKER equals "valgrind" and remove "-DVALGRIND" from our own pipelines.
* trace: enable tracing by defaultEdward Thomson2019-11-271-1/+1
| | | | | | | | | Tracing is meant to be extremely low-impact when not enabled. We currently ship no tracing calls in libgit2, but if / when we do, the tracing infrastructure is created to skip tracing as quickly as possible. It should compile to a simple test when tracing is off. Thus, there's on reason to not enable it by default.
* cmake: update minimum CMake version to v3.5.1Patrick Steinhardt2019-10-101-8/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* cmake: move _WIN32_WINNT definitions to rootTobias Nießen2019-08-171-0/+5
|
* tests: execute leak checker via CTest directlyPatrick Steinhardt2019-07-201-0/+1
| | | | | | | | | | | | | | | 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.
* clang: disable documentation-deprecated-syncEdward Thomson2019-06-241-0/+4
| | | | | | | | | | | Add the `-Wno-documentation-deprecated-sync` switch when compiling with clang, since our documentation adds `deprecated` markers, but we do not add the deprecation attribute in the code itself. (ie, the code is out of sync with the docs). In fact, we do not _want_ to mark these items as deprecated in the code, at least not yet, as we are not quite ready to bother our end-users with this since they're not going away.
* mingw: disable format specification warningsEdward Thomson2019-06-241-3/+11
| | | | | | | MinGW uses gcc, which expects POSIX formatting for printf, but uses the Windows C library, which uses its own format specifiers. Therefore, it gets confused about format specifiers. Disable warnings for format specifiers.
* cmake: default NTLM client to off if no HTTPS supportPatrick Steinhardt2019-06-171-1/+5
| | | | | | | | | If building libgit2 with `-DUSE_HTTPS=NO`, then CMake will generate an error complaining that there's no usable HTTPS backend for NTLM. In fact, it doesn't make sense to support NTLM when we don't support HTTPS. So let's should just have NTLM default to OFF when HTTPS is disabled to make life easier and to fix our OSSFuzz builds failing.
* cmake: Modulize our TLS & hash detectionEtienne Samson2019-06-141-3/+1
| | | | | | | | | | | | | | | The interactions between `USE_HTTPS` and `SHA1_BACKEND` have been streamlined. Previously we would have accepted not quite working configurations (like, `-DUSE_HTTPS=OFF -DSHA1_BACKEND=OpenSSL`) and, as the OpenSSL detection only ran with `USE_HTTPS`, the link would fail. The detection was moved to a new `USE_SHA1`, modeled after `USE_HTTPS`, which takes the values "CollisionDetection/Backend/Generic", to better match how the "hashing backend" is selected, the default (ON) being "CollisionDetection". Note that, as `SHA1_BACKEND` is still used internally, you might need to check what customization you're using it for.
* http-parser: use our bundled http-parser by defaultethomson/urlparse_empty_portEdward Thomson2019-06-131-1/+1
| | | | | | | | | | | Our bundled http-parser includes bugfixes, therefore we should prefer our http-parser until such time as we can identify that the system http-parser has these bugfixes (using a version check). Since these bugs are - at present - minor, retain the ability for users to force that they want to use the system http-parser anyway. This does change the cmake specification so that people _must_ opt-in to the new behavior knowingly.
* ntlm: add ntlmclient as a dependencyEdward Thomson2019-06-101-0/+4
| | | | Include https://github.com/ethomson/ntlmclient as a dependency.
* regex: use REGEX_BACKEND as the cmake option nameEdward Thomson2019-05-211-1/+1
| | | | This avoids any misunderstanding with the REGEX keyword in cmake.
* regex: optionally use PCRE2Edward Thomson2019-05-191-1/+1
| | | | | | | Use PCRE2 and its POSIX compatibility layer if requested by the user. Although PCRE2 is adequate for our needs, the PCRE2 POSIX layer as installed on Debian and Ubuntu systems is broken, so we do not opt-in to it by default to avoid breaking users on those platforms.
* regex: allow regex selection in cmakeEdward Thomson2019-05-191-0/+1
| | | | | | | | | | | | | Users can now select which regex implementation they want to use: one of the system `regcomp_l`, the system PCRE, the builtin PCRE or the system's `regcomp`. By default the system `regcomp_l` will be used if it exists, otherwise the system PCRE will be used. If neither of those exist, then the builtin PCRE implementation will be used. The system's `regcomp` is not used by default due to problems with locales.
* deprecation: optionally enable hard deprecationEdward Thomson2019-02-141-0/+5
| | | | | | | Add a CMake option to enable hard deprecation; the resultant library will _not_ include any deprecated functions. This may be useful for internal CI builds that create libraries that are not shared with end-users to ensure that we do not use deprecated bits internally.
* deprecation: ensure we GIT_EXTERN deprecated funcsEdward Thomson2019-02-141-3/+0
| | | | | | | | | | 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.
* MSVC: ignore empty compilation units (warning LNK4221)Edward Thomson2019-01-251-0/+3
| | | | | | | A number of source files have their implementation #ifdef'd out (because they target another platform). MSVC warns on empty compilation units (with warning LNK4221). Ignore warning 4221 when creating the object library.
* deprecation: define GIT_DEPRECATE_HARD internallyEdward Thomson2019-01-251-1/+3
| | | | | Ensure that we do not use any deprecated functions in the library source, test code or examples.
* cmake: error when STDCALL is specifiedEdward Thomson2019-01-171-0/+4
| | | | | | | To explicitly break end-users who were specifying STDCALL, explicitly fail the cmake process to ensure that they know that they need to change their bindings. Otherwise, we would quietly ignore their option and the resulting cdecl library would produced undefined behavior.
* Use cdecl calling conventions on Win32Edward Thomson2019-01-171-12/+2
| | | | | | | | | | | | | | | | | | | The recommendation from engineers within Microsoft is that libraries should have a calling convention specified in the public API, and that calling convention should be cdecl unless there are strong reasons to use a different calling convention. We previously offered end-users the choice between cdecl and stdcall calling conventions. We did this for presumed wider compatibility: most Windows applications will use cdecl, but C# and PInvoke default to stdcall for WINAPI compatibility. (On Windows, the standard library functions are are stdcall so PInvoke also defaults to stdcall.) However, C# and PInvoke can easily call cdecl APIs by specifying an annotation. Thus, we will explicitly declare ourselves cdecl and remove the option to build as stdcall.
* cmake: remove unconditional -Wno-deprecated-declaration on APPLEEtienne Samson2019-01-101-3/+0
| | | | | | | | | | | | After taking into consideration the following, I think this should be removed : - OpenSSL isn't the default on Apple platforms - you have to jump through hoops to get CMake to use OpenSSL on macOS (headers aren't in `/usr/include`, so you have to provide `-DOPENSSL_*` overrides) - users are likely (as getting anywhere near the installed 0.9.8 version is insanity IMHO) to package a "modern" version, which wouldn't be marked as deprecated
* Merge pull request #4895 from pks-t/pks/unused-warningsPatrick Steinhardt2018-11-291-2/+2
|\ | | | | Unused function warnings
| * cmake: enable warnings for unused const variablesPatrick Steinhardt2018-11-281-1/+1
| | | | | | | | | | | | | | | | Together with the warnings for unused warnings, we always had warnings for unused constant variables disabled since commit 823c0e9cc (Fix broken logic for attr cache invalidation, 2014-04-17). As we have now fixed all occurrences of such variables, we can safely enable those warnings again.
| * cmake: enable warnings for unused functionsPatrick Steinhardt2018-11-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Ever since commit 823c0e9cc (Fix broken logic for attr cache invalidation, 2014-04-17), we have completely disabled warnings for unused functions. The only comment that was added back then is about "annoying extra warnings" from Clang, but in fact we shouldn't just ignore warnings about functions which aren't used at all. Instead, the right thing would be to either only conditionally compile functions that aren't used in all configurations or, alternatively, to remove functions that aren't required at all. As remaining instances of unused functions have been removed in the last two commits, re-enable the warning.
* | CMake: disable deprecated documentation syncEdward Thomson2018-11-281-0/+1
| | | | | | | | | | | | | | | | The `-Wdocumentation-deprecated-sync` option will warn when there is a doxygen `\deprecated` tag but there is no corresponding deprecation attribute on the function. We want to encourage users to not use particular APIs by marking them deprecated in the documentation without necessarily raising a compiler warning by marking an item as deprecated.
* | http: remove cURLEdward Thomson2018-11-281-1/+0
|/ | | | | We previously used cURL to support HTTP proxies. Now that we've added this support natively, we can remove the curl dependency.
* cmake: correct comment from libssh to libssh2ethomson/libssh2_not_libsshEdward Thomson2018-10-171-1/+1
| | | | | We use libssh2. We do not use libssh. Make sure to disambiguate them correctly.
* cmake: explicitly enable int-conversion warningsPatrick Steinhardt2018-10-051-0/+1
| | | | | | | | While GCC enables int-conversion warnings by default, it will currently only warn about such errors even in case where "-DENABLE_WERROR=ON" has been passed to CMake. Explicitly enable int-conversion warnings by using our `ENABLE_WARNINGS` macro, which will automatically use "-Werror=int-conversions" in case it has been requested by the user.
* cmake: enable new quoted argument policy CMP0054Patrick Steinhardt2018-10-041-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | Quoting from CMP0054's documentation: Only interpret if() arguments as variables or keywords when unquoted. CMake 3.1 and above no longer implicitly dereference variables or interpret keywords in an if() command argument when it is a Quoted Argument or a Bracket Argument. The OLD behavior for this policy is to dereference variables and interpret keywords even if they are quoted or bracketed. The NEW behavior is to not dereference variables or interpret keywords that have been quoted or bracketed. The previous behaviour could be quite unexpected. Quoted arguments might be expanded in case where the value of the argument corresponds to a variable. E.g. `IF("MONKEY" STREQUAL "MONKEY")` would have been expanded to `IF("1" STREQUAL "1")` iff `SET(MONKEY 1)` was set. This behaviour was weird, and recent CMake versions have started to complain about this if they see ambiguous situations. Thus we want to disable it in favor of the new behaviour.
* cmake: remove spaces between `IF` and `(` for policiesPatrick Steinhardt2018-10-041-2/+2
| | | | | | Our CMake coding style dictates that there should be no space between `IF` and its opening `(`. Adjust our policy statements to honor this style.
* Merge pull request #4812 from libgit2/ethomson/ci-refactorEdward Thomson2018-09-291-2/+0
|\ | | | | CI: refactoring
| * Revert "clar: introduce CLAR_XML option"Edward Thomson2018-09-101-2/+0
| | | | | | | | | | This reverts commit a2d73f5643814cddf90d5bf489332e14ada89ab8. Using clar to propagate the XML settings was a mistake.
* | cmake: enable -Wformat and -Wformat-securitycmn/format-securityCarlos Martín Nieto2018-09-171-0/+2
|/ | | | | We do not currently have any warnings in this regard, but it's good practice to have them on in case we introduce something.
* clar: introduce CLAR_XML optionEdward Thomson2018-09-061-0/+2
| | | | | | 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.
* util: make the qsort_r check work on macOSEtienne Samson2018-08-241-0/+1
| | | | | | | | This performs a compile-check by using CMake support, to differentiate the GNU version from the BSD version of qsort_r. Module taken from 4f252abea5f1d17c60f6ff115c9c44cc0b6f1df6, which I've checked against CMake 2.8.11.
* cmake: remove USE_SANITIZER and USE_COVERAGE optionsPatrick Steinhardt2018-08-031-16/+0
| | | | | | | | | | | Both the USE_SANITIZER and USE_COVERAGE options are convenience options that turn on a set of CFLAGS. Despite our own set of CFLAGS required to build libgit2, we have no real business to mess with them, though, as they can easily be passed in by the user via specifying the CFLAGS environment variable. The reasoning behind not providing them is that as soon as we start adding those for some usecases, users might ask for other sets of CFLAGS catering to their specific need in another usecase. Thus, we do not want to support them here.
* cmake: fix the unholy options alignment messPatrick Steinhardt2018-08-031-31/+32
|
* cmake: error out if required C flags are not supportedPatrick Steinhardt2018-08-031-6/+11
| | | | | | | We do want to notify users compiling our source code early on if they try to use C flags which aren't supported. Add a new macro `AddCFlag`, which results in a fatal error in case the flag is not supported, and use it for our fuzzing flags.
* fuzzers: rename "fuzz" directory to match our stylePatrick Steinhardt2018-08-031-1/+1
| | | | | | | | | | | Our layout uses names like "examples" or "tests" which is why the "fuzz" directory doesn't really fit in here. Rename the directory to be called "fuzzers" instead. Furthermore, we rename the fuzzer "fuzz_packfile_raw" to "packfile_raw_fuzzer", which is also in line with the already existing fuzzer at google/oss-fuzz. While at it, rename the "packfile_raw" fuzzer to instead just be called "packfile" fuzzer.
* fuzzers: add build support and instructionslhchavez2018-08-031-0/+33
| | | | | | This change adds support for building a fuzz target for exercising the packfile parser, as well as documentation. It also runs the fuzzers in Travis to avoid regressions.
* cmake: enforce C90 standardPatrick Steinhardt2018-07-131-1/+1
| | | | | | | | | | | | | 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.
* cmake: resolve libraries found by pkg-configPatrick Steinhardt2018-05-091-1/+1
| | | | | | | | | | | | | | | | | | | 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`.
View Lorry Controller Status