CMake module to enable code coverage easily and generate coverage reports with CMake targets.

Overview

CMake-codecov

Travis Codecov

CMake module to enable code coverage easily and generate coverage reports with CMake targets.

Include into your project

To use Findcodecov.cmake, simply add this repository as git submodule into your own repository

mkdir externals
git submodule add git://github.com/RWTH-HPC/CMake-codecov.git externals/CMake-codecov

and adding externals/cmake-codecov/cmake to your CMAKE_MODULE_PATH

set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/externals/CMake-codecov/cmake" ${CMAKE_MODULE_PATH})

If you don't use git or dislike submodules you can copy the Findcodecov.cmake, FindGcov.cmake and FindLcov.cmake files into your repository. Be careful when there are version updates of this repository!

Next you have to include the codecov package. This can be done in your root CMake file, or in the file were your targets will be defined:

# enable code coverage
find_package(codecov)

For coverage evaluation you have to add coverage_evaluate() after all other targets have been defined. A good place for this is your root CMakeLists.txt in the last lines after you included your sub-directories and added targets.

Usage

To enable coverage support in general, you have to enable ENABLE_COVERAGE option in your CMake configuration. You can do this by passing -DENABLE_COVERAGE=On on your command line or with your graphical interface.

If coverage is supported by your compiler, the specified targets will be build with coverage support. If your compiler has no coverage capabilities (I asume intel compiler doesn't) you'll get a warning but CMake will continue processing and coverage will simply just be ignored.

Compiler issues

Different compilers may be using different implementations for code coverage. If you'll try to cover targets with C and Fortran code but don't use gcc & gfortran but clang & gfortran, this will cause linking problems. To avoid this, such problems will be detected and coverage will be disabled for such targets.

Even C only targets may cause problems, if e.g. clang compiles the coverage for an older gcov version than the one is shipped with your distribution. FindGcov.cmake tries to find a compatible coverage evaluation tool to avoid this issue, but may fail. In this case you should check coverage with a different compiler or install a compatible coverage tool.

File extensions

Starting with CMake 3.14, this module will use the last file extension only (i.e. .c for a.b.c). Prior versions will use the full file extension starting with the first dot in the file name.

Build targets with coverage support

To enable coverage support you have two options: You can mark targets explictly for coverage by adding your target with add_coverage(). This call must be done in the same directory as your add_executable()or add_library() call:

add_executable(some_exe foo.c bar.c)
add_coverage(some_exe)

add_library(some_lib foo.c bar.c)
add_coverage(some_lib)

Executing your program

To be able to evaluate your coverage data, you have to run your application first. Some projects include CMake tests - it might me a good idea to execute them now by make test, but you can run your application however you want (e.g. by running ./a.out).

Evaluating coverage data

Gcov

Gcov is a console program to evaluate the generated coverage data. You can evaluate the data by calling the following targets:

target description
-gcov Evaluate coverage data for target .
gcov Evaluate the coverage data of all your targets. Warning: You have to run programs generated by every target before you can call this target without any error. Otherwise you might get errors, if *.gcda files will not be found.

The files generated by Gcov reside in the binary directory of the target you're evaluating the coverage data for (e.g. for target bar in this repository it'll be ${CMAKE_BINARY_DIR}/src/bar/CMakeFiles/bar.dir/).

Lcov

Lcov is a console program to evaluate the generate coverage data, but instead of writing the results into a copy of the original source file (like Gcov does) a HTML report will be generated, which is much easier to read than several gcov files.

target description
-geninfo Evaluate coverage data for target .
-genhtml Generate a report for a specific target (and only this one, even if it has dependencies!). This target will call -geninfo before. Reports will be generated in ${CMAKE_BINARY_DIR}/lcov/html/ .
lcov-geninfo Evaluate the coverage data of all your targets.
lcov-genhtml Generate a single report for all evaluated data that is available now. Note: You have to call -geninfo for all targets you want to have in this report before calling this target or lcov-geninfo. You can use this option, if you like to have a single report for the targets foo and bar together, but without all the other targets. Reports will be generated in ${CMAKE_BINARY_DIR}/lcov/html/selected_targets.
lcov Generate a single report for all targets. This target will call lcov-geninfo before. Reports will be generated in ${CMAKE_BINARY_DIR}/lcov/html/all_targets.
Excluding files from coverage reports

If you want to exclude some files from your coverage reports by lcov --remove subcommand, you can append their path patterns to LCOV_REMOVE_PATTERNS in your CMakeLists.txt like a following example.

list(APPEND LCOV_REMOVE_PATTERNS "'${PROJECT_SOURCE_DIR}/extlib/*'")

Note that asterisks in patterns should not be expanded by the shell interpreter.

Contribute

Anyone is welcome to contribute. Simply fork this repository, make your changes in an own branch and create a pull-request for your change. Please do only one change per pull-request.

You found a bug? Please fill out an issue and include any data to reproduce the bug.

Contributors

Alexander Haase

License

CMake-codecov is released under the 3-clause BSD license. See the LICENSE file for more information.

Copyright © 2015-2020 RWTH Aachen University, Federal Republic of Germany.

Issues
  • gcov generation fails with Ninja generator

    gcov generation fails with Ninja generator

    Steps to reproduce:

    CMakeLists.txt:

    cmake_minimum_required(VERSION 3.4)
    project(test CXX)
    set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake/codecov/cmake" ${CMAKE_MODULE_PATH})
    find_package(codecov)
    add_executable(foo test.cc)
    add_coverage(foo)
    

    test.cc:

    #include <iostream>
    using namespace std;
    int main(int argc, char **argv)
    {
        cout << "Hello World!\n";
        return 0;
    }
    

    Setup:

    $ git submodule add https://github.com/RWTH-ELP/CMake-codecov.git cmake/codecov
    $ mkdir build
    $ cd build
    $ CXX=clang++ CC=clang cmake -G Ninja .. -DENABLE_COVERAGE=On
    $ ninja-build -v foo
    $ ./foo
    $ ninja-build -v foo-gcov
    

    Actual result:

    $ ninja-build -v foo-gcov
    [1/1] cd /home/juser/cmake-codecov-test/build/CMakeFiles/foo.dir && LLVM_COV_BIN=/usr/bin/llvm-cov /home/juser/cmake-codecov-test/cmake/codecov/cmake/llvm-cov-wrapper /home/juser/cmake-codecov-test/build/CMakeFiles/foo.dir/test.cc.gcno > /dev/null
    ../test.cc: No such file or directory
    $ ninja-build -v foo-gcov
    ninja: no work to do.
    

    Expected result:

    A .gcov file under in the build directory, i.e. CMakeFiles/foo.dir/test.cc.gcov.

    I tested it on Fedora 23.

    When compiling with the CMake makefile generator the gcov report is generated as expected.

    bug enhancement 
    opened by gsauthof 7
  • get_filename_component doesn't cover .t.cpp

    get_filename_component doesn't cover .t.cpp

    Some source code layout guidelines suggest to name test source files with the combined extension .t.cpp. Unfortunately the use of get_filename_component at https://github.com/RWTH-HPC/CMake-codecov/blob/9a24e83a901e4acee01786ff2c75559f580bb772/cmake/Findcodecov.cmake#L136 is not adequate in such a situation, because it extracts the maximal extension .t.cpp instead of just .cpp, which makes the source file not recognizable.

    An alternative would be the use of a regular expression, i.e. instead of:

    get_filename_component(FILE_EXT "${FILE}" EXT)
    string(TOLOWER "${FILE_EXT}" FILE_EXT)
    string(SUBSTRING "${FILE_EXT}" 1 -1 FILE_EXT)
    

    one could use

    string(REGEX REPLACE "^.*\\.([^\\.]+)$" "\\1" FILE_EXT "${FILE}")
    string(TOLOWER "${FILE_EXT}" FILE_EXT)
    
    opened by giacomini 6
  • GCov not detected on OS X travis image

    GCov not detected on OS X travis image

    I am trying to use CMake-codecov to capture code coverage for Catch and after some bumbling around I got it to work properly under Linux for both GCC and Clang.

    However, I ran into trouble when I was trying to integrate it with OS X builds. The scripts properly detect that AppleClang supports coverage, finds lcov, but then is unable to find gcov, with this output

    CMake Warning at CMake/FindGcov.cmake:129 (message):
      No coverage evaluation binary found for AppleClang.
    
    Call Stack (most recent call first):
      CMake/Findcodecov.cmake:248 (add_gcov_target)
      CMake/Findcodecov.cmake:38 (add_coverage_target)
      CMakeLists.txt:308 (add_coverage)
    
    
    CMake Warning at CMake/FindLcov.cmake:154 (message):
      No coverage evaluation binary found for AppleClang.
    
    Call Stack (most recent call first):
      CMake/FindLcov.cmake:39 (lcov_capture_initial_tgt)
      CMake/Findcodecov.cmake:249 (add_lcov_target)
      CMake/Findcodecov.cmake:38 (add_coverage_target)
      CMakeLists.txt:308 (add_coverage)
    
    
    CMake Warning at CMake/FindLcov.cmake:245 (message):
      No coverage evaluation binary found for AppleClang.
    
    Call Stack (most recent call first):
      CMake/FindLcov.cmake:42 (lcov_capture_tgt)
      CMake/Findcodecov.cmake:249 (add_lcov_target)
      CMake/Findcodecov.cmake:38 (add_coverage_target)
      CMakeLists.txt:308 (add_coverage)
    

    The full travis output can be found here.

    Btw, thanks for the script. After I stopped being dumb about using it on Linux, it worked nicely.

    bug 
    opened by horenmar 5
  • kind license change request

    kind license change request

    The project looks quite good. However, I can't use it in most of my github projects due to the restriction to GPL only license. Would it be considerable for you to change the license to something very liberal, so it becomes a no brainer for most project maintainers to add your cmake code to their projects?

    enhancement question 
    opened by beku 5
  • Skip lookup of compiler flags for unsopported languages (#33)

    Skip lookup of compiler flags for unsopported languages (#33)

    This isn't the prettiest solution in the world, but it is simple enough and should work with older CMake versions. The diff does a poor job of showing it, but the section in the new if() is unmodified save for the indentation.

    opened by Morwenn 4
  • Test if compiler is compatible to gcov

    Test if compiler is compatible to gcov

    Clang and gcov may support different interfaces. This can cause warnings and even crashes. FindGcov.cmake should implement a check to check if all compilers are compatible to gcov.

    Another way could be to check if the compiler has an own gcov implementation, e.g. clang ships a binary named llvm-gcov which may be used as alternative to gcov.

    enhancement 
    opened by alehaa 2
  • Findcodecov.cmake looks for RC compiler with MinGW-w64

    Findcodecov.cmake looks for RC compiler with MinGW-w64

    I am using CMake-covedoc on Windows 10 with MinGW-w64. It works great but the script includes some logs that made me think there were issues at first and which might be silenced to avoid confusion:

    -- Try GNU code coverage flag = [-O0 -g -fprofile-arcs -ftest-coverage]
    -- Performing Test COVERAGE_FLAG_DETECTED
    -- Performing Test COVERAGE_FLAG_DETECTED - Success
    -- Try  code coverage flag = [-O0 -g -fprofile-arcs -ftest-coverage]
    CMake Warning at cmake/Findcodecov.cmake:121 (message):
      Code coverage is not available for compiler.  Targets using this compiler
      will be compiled without it.
    Call Stack (most recent call first):
      testsuite/CMakeLists.txt:42 (find_package)
    
    
    -- Try  code coverage flag = [-O0 -g --coverage]
    CMake Warning at cmake/Findcodecov.cmake:121 (message):
      Code coverage is not available for compiler.  Targets using this compiler
      will be compiled without it.
    Call Stack (most recent call first):
      testsuite/CMakeLists.txt:42 (find_package)
    

    What is not obvious from these logs is that after successfully finding MinGW-w64 g++, Findcodecov.cmake looks for a compiler for RC (which is among the languages in ENABLED_LANGUAGES), fails to find a compiler (there is no CMAKE_RC_COMPILER_ID) and as a result doesn't detect any flag.

    To avoid those logs, I see two solutions:

    • Specifically ignoring RC when found in ENABLED_LANGUAGES.
    • Skipping the flags lookup and displaying a warning when ${COMPILER} is empty.

    Both solutions could probably live side by side in order to avoid the proposed warning anyway when RC isn't found.

    Thanks again for the project, it's really nice!

    opened by Morwenn 1
  • Case mismatch in passing lcov to find_package_handle_standard_args

    Case mismatch in passing lcov to find_package_handle_standard_args

    The latest version of cmake warns at https://github.com/RWTH-HPC/CMake-codecov/blob/2682f89e3c7e54e915ea4de3db093a0756265393/cmake/FindLcov.cmake#L56

    [cmake] CMake Warning (dev) at /usr/local/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:272 (message):
    [cmake]   The package name passed to `find_package_handle_standard_args` (lcov) does
    [cmake]   not match the name of the calling package (Lcov).  This can lead to
    [cmake]   problems in calling code that expects `find_package` result variables
    [cmake]   (e.g., `_FOUND`) to follow a certain pattern.
    [cmake] Call Stack (most recent call first):
    [cmake]   cmake/FindLcov.cmake:56 (find_package_handle_standard_args)
    [cmake]   cmake/Findcodecov.cmake:271 (find_package)
    [cmake]   CMakeLists.txt:49 (find_package)
    [cmake] This warning is for project developers.  Use -Wno-dev to suppress it.
    

    The fix is simply to pass Lcov instead of lcov.

    opened by giacomini 1
  • When comparing for a file's language type only consider the last part of the file extension

    When comparing for a file's language type only consider the last part of the file extension

    Currently, code coverage is failing due to the naming of files in my project. Test files take the form .tests.cpp. This is failing because the code coverage module then looks to see if the file extension ".tests.cpp" is supported by any compiler and unsurprisingly it's not.

    This is caused by calling the get_filename_component function with the EXT parameter. This is fixed by calling with the LAST_EXT parameter which only considers file extension after the final dot separator.

    opened by Twon 1
  • Re-capture data if a gcda file changed

    Re-capture data if a gcda file changed

    Before in

    cmake .. ENABLE_COVERAGE=1
    make lcov
    make test
    make lcov
    

    , the second make lcov would not cause a re-capture of coverage because a target capture file has no dependency on a .gcda file.

    I added a dependency by forcing the creation of one (touch). It is only used if it has a non-zero size (test -s).

    opened by madebr 1
  • Add a minimal .gitignore file

    Add a minimal .gitignore file

    In git, ignore all build* directories by default. This is particularly handy if we want to use the standard mkdir build & cd build & cmake .. commands. Also, some IDEs (e.g. VSCode) do similar things.

    opened by rbost 1
  • use cmake current source dir to get correct path

    use cmake current source dir to get correct path

    Using the repo as third party library using FetchContent failed:

     FetchContent_Declare(
           cmake-codecov
           GIT_REPOSITORY https://github.com/RWTH-HPC/CMake-codecov.git
    )
    FetchContent_MakeAvailable(cmake-codecov) 
    

    with the following error message:

    CMake Error at build/_deps/cmake-codecov-src/src/libfoo/CMakeLists.txt:13 (add_coverage):
      Unknown CMake command "add_coverage".
    

    This PR fix the issue by using the correct cmake variable in CMakeLists.txt

    opened by callalilychen 2
  • Ensure no left over state is left in the required flags variable

    Ensure no left over state is left in the required flags variable

    I'm raising this PR to fix a bug when using the code coverage modules with a build that includes the HDF5 library. HDF5 uses the CMAKE_REQUIRED_FLAGS with try_compile, however, because it appends to CMAKE_REQUIRED_FLAGS its is picking up the leftover code coverage flags from the coverage module. All of the calls to try_compile now fail because gcov is not added as a linker flag as well:

    -- try_compile: {COMPILE_DEFINITIONS: -DSTDC_HEADERS -O0 -g -fprofile-arcs -ftest-coverage -DHAVE_SYS_TIME_H -DHAVE_UNISTD_H -DHAVE_SYS_TYPES_H -DHAVE_SYS_SOCKET_H, LINK_LIBRARIES: m;dl, OUTPUT_VARIABLE: Change Dir: /home/toro/build/CMakeFiles/CMakeTmp
    
    Run Build Command(s):/usr/local/bin/ninja cmTC_df3b4 && [1/2] Building C object CMakeFiles/cmTC_df3b4.dir/HDFTests.c.o
    [2/2] Linking C executable cmTC_df3b4
    FAILED: cmTC_df3b4 
    : && /opt/ccache-3.7.9/bin/cc   -static-libstdc++ -static-libgcc -pthread -lrt -ldl CMakeFiles/cmTC_df3b4.dir/HDFTests.c.o  -o cmTC_df3b4  -lm  -ldl && :
    /home/antony/packages/hdf5/original/config/cmake_ext_mod/HDFTests.c:115: error: undefined reference to '__gcov_init'
    /home/antony/packages/hdf5/original/config/cmake_ext_mod/HDFTests.c:115: error: undefined reference to '__gcov_exit'
    CMakeFiles/cmTC_df3b4.dir/HDFTests.c.o(.data+0x60): error: undefined reference to '__gcov_merge_add'
    collect2: error: ld returned 1 exit status
    ninja: build stopped: subcommand failed.
    

    While is this arguably an error with the way HDF5 uses CMAKE_REQUIRED_FLAGS I think it makes sense to fix this here, because there may be other libraries out in the wild that makes similar assumptions about the usage of CMAKE_REQUIRED_FLAGS. Additionally, as this is the location the values originate from, and they are not longer needed after the check this seems the correct place to address the issue by resetting the values to their default state.

    opened by Twon 2
  • Automatic tests and zerocounter

    Automatic tests and zerocounter

    I just try to use CMake-codecov (I'm new to lcov, just learning, so sorry if my question is out of scope)

    I want to automatically call check target before calling lcov. after calling coverage_evaluate() at the end of main CMakeLists.txt, I added add_dependencies(lcov check) But I have one issue, I want to "zerocounter" lcov data before tests, to have fresh results in case of rebuild. I have done

    add_custom_command(TARGET lcov-zerocounter COMMAND ${LCOV_BIN} --quiet --zerocounter --directory ${CMAKE_BINARY_DIR})
    add_dependencies(check lcov-zerocounter)
    

    But I'm asking myself should this be present directly in CMake-codecov ? or is there a better way to handle lcov data cleanup before capture. Thanks.

    opened by dlyr 3
  • WIP: Support for lcov/gcov with Ninja

    WIP: Support for lcov/gcov with Ninja

    This is an attempt to better integrate the Ninja build system (issue #29, but also #6).

    It is just meant for discussion, for there are still a few things to sort out, e.g. the target versions of CMake, Ninja, gcc, ... It's a bit of a mess.

    Whatever the response, it would be nice to have a github action that runs tests for at least some combinations of the above.

    opened by giacomini 1
  • lcov targets fail with Ninja

    lcov targets fail with Ninja

    The same example provided in issue #6 shows that also the support for lcov is failing when using the Ninja generator.

    $ cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug -DENABLE_COVERAGE=ON ..
    $ ninja -v foo
    [1/2] /usr/bin/c++    -g    -O0 -g -fprofile-arcs -ftest-coverage -MD -MT CMakeFiles/foo.dir/test.cc.o -MF CMakeFiles/foo.dir/test.cc.o.d -o CMakeFiles/foo.dir/test.cc.o -c ../test.cc
    [2/2] : && /usr/bin/c++  -g  -O0 -g -fprofile-arcs -ftest-coverage CMakeFiles/foo.dir/test.cc.o  -o foo   && :
    $ ./foo
    Hello World!
    $ ninja -v foo-genhtml
    [1/8] cd /home/giaco/tmp/lcov-cmake/build && /usr/bin/geninfo --quiet --base-directory /home/giaco/tmp/lcov-cmake --initial --gcov-tool /usr/bin/gcov-7 --output-filename /home/giaco/tmp/lcov-cmake/build/CMakeFiles/foo.dir/test.cc.info.init --no-external /home/giaco/tmp/lcov-cmake/build/CMakeFiles/foo.dir/test.cc.gcno
    geninfo: WARNING: could not open /home/giaco/tmp/test.cc
    geninfo: WARNING: some exclusion markers may be ignored
    [2/8] cd /home/giaco/tmp/lcov-cmake/build && cat /home/giaco/tmp/lcov-cmake/build/CMakeFiles/foo.dir/test.cc.info.init > /home/giaco/tmp/lcov-cmake/build/lcov/data/init/foo.info.raw
    [3/8] cd /home/giaco/tmp/lcov-cmake/build && /usr/bin/lcov --quiet -a /home/giaco/tmp/lcov-cmake/build/lcov/data/init/foo.info.raw --output-file /home/giaco/tmp/lcov-cmake/build/lcov/data/init/foo.info --base-directory /home/giaco/tmp/lcov-cmake --initial && /usr/bin/lcov --quiet -r /home/giaco/tmp/lcov-cmake/build/lcov/data/init/foo.info --output-file /home/giaco/tmp/lcov-cmake/build/lcov/data/init/foo.info --initial
    FAILED: lcov/data/init/foo.info 
    cd /home/giaco/tmp/lcov-cmake/build && /usr/bin/lcov --quiet -a /home/giaco/tmp/lcov-cmake/build/lcov/data/init/foo.info.raw --output-file /home/giaco/tmp/lcov-cmake/build/lcov/data/init/foo.info --base-directory /home/giaco/tmp/lcov-cmake --initial && /usr/bin/lcov --quiet -r /home/giaco/tmp/lcov-cmake/build/lcov/data/init/foo.info --output-file /home/giaco/tmp/lcov-cmake/build/lcov/data/init/foo.info --initial
    lcov: ERROR: no valid records found in tracefile /home/giaco/tmp/lcov-cmake/build/lcov/data/init/foo.info.raw
    ninja: build stopped: subcommand failed.
    

    At least the first error (geninfo: WARNING: could not open /home/giaco/tmp/test.cc) can be fixed passing ${CMAKE_BINARY_DIR} instead of ${CMAKE_SOURCE_DIR} to the --base-directory option of geninfo. This because Ninja works with paths relative to the binary directory.

    Everything works fine with the Makefile generator, which works with absolute paths.

    opened by giacomini 3
Project to enable using CMake from a Maven build.

CMake-Maven-Project Introduction A Maven project for the CMake build system. It can be used by including it as a plugin within your Maven project's po

null 58 Jul 13, 2022
unmaintained - CMake module to activate certain C++ standard, feature checks and appropriate automated workarounds - basically an improved version of cmake-compile-features

Compatibility This library provides an advanced target_compile_features() and write_compiler_detection_header(). The problem with those is that they a

Jonathan Müller 72 Apr 14, 2022
[CMake] [BSD-2] CMake module to find ICU

FindICU.cmake A CMake module to find International Components for Unicode (ICU) Library Note that CMake, since its version 3.7.0, includes a FindICU m

julp 29 Apr 26, 2022
Coveralls JSON coverage generator and uploader for CMake

Coveralls Generator for CMake This is a set of CMake scripts that are meant to be used to generate and upload coverage data to http://coveralls.io/. T

Joakim Söderberg 81 Jul 11, 2022
CMake module for building IDL files with MIDL and generating CLR DLL using Tlbimp

FindIDL CMake module for building IDL files with MIDL and generating CLR DLL using Tlbimp. Introduction Requirements Usage find_package() add_idl() ad

Apriorit Inc. 16 Jul 26, 2022
curl cmake module libcurl build with msvc x86

curl-msvc Infomation curl cmake module libcurl build with MSVC10.0 arch (x86 | i386) source from https://github.com/curl/curl tags: curl-7_79_1 Usage

Jason Payne 0 May 16, 2022
CMake module for downloading an external project's source at configure time

DownloadProject Platform Build status Linux Mac OSX Windows (VS2015) This repository contains a generalized implementation for downloading an external

Crascit Pty Ltd 426 Aug 9, 2022
CMake module to speed up builds.

cotire Cotire (compile time reducer) is a CMake module that speeds up the build process of CMake based build systems by fully automating techniques as

Sascha Kratky 1.3k Aug 11, 2022
CMake module for building Windows Installer packages with WiX toolset

FindWiX CMake module for building Windows Installer packages with WiX toolset Introduction Requirements Usage find_package() wix_add_project() WiX com

Apriorit Inc. 11 Aug 5, 2022
CMake find module for Intel Threading Building Blocks

FindTBB Module FindTBB is a CMake find package module for Intel® Threading Building Blocks (TBB). Usage The signature of the TBB find module in CMake

Justus Calvin 82 Jun 30, 2022
CMake module for Mathematica.

FindMathematica FindMathematica is a CMake module that tries to find a Wolfram Language installation and provides CMake functions for its C/C++ interf

Sascha Kratky 50 Jul 31, 2022
CMake scripts for painless usage of SuiteSparse+METIS from Visual Studio and the rest of Windows/Linux/OSX IDEs supported by CMake

CMake scripts for painless usage of Tim Davis' SuiteSparse (CHOLMOD,UMFPACK,AMD,LDL,SPQR,...) and METIS from Visual Studio and the rest of Windows/Lin

Jose Luis Blanco-Claraco 385 Aug 2, 2022
📦 CMake's missing package manager. A small CMake script for setup-free, cross-platform, reproducible dependency management.

Setup-free CMake dependency management CPM.cmake is a CMake script that adds dependency management capabilities to CMake. It's built as a thin wrapper

CPM.cmake 1.3k Aug 7, 2022
CMake checks cache helper modules – for fast CI CMake builds!

cmake-checks-cache Cross platform CMake projects do platform introspection by the means of "Check" macros. Have a look at CMake's How To Write Platfor

Cristian Adam 59 Jul 7, 2022
cmake-font-lock - Advanced, type aware, highlight support for CMake

cmake-font-lock - Advanced, type aware, highlight support for CMake

Anders Lindgren 37 Dec 30, 2021
cmake-avr - a cmake toolchain for AVR projects

cmake-avr - a cmake toolchain for AVR projects Testing the example provided The toolchain was created and tested within the following environment: Lin

Matthias Kleemann 156 Jun 20, 2022
Make CMake less painful when trying to write Modern Flexible CMake

Izzy's eXtension Modules IXM is a CMake library for writing Modern flexible CMake. This means: Reducing the amount of CMake written Selecting reasonab

IXM 105 Jul 18, 2022
A CMake addon that avoids you writing boilerplate code for resource management.

SHader INJ(I)ector SHINJI (originally SHader INJector) is a CMake addon that avoids you writing boilerplate code for resource management and exposes s

Lorenzo Rutayisire 6 Mar 21, 2022
A set of cmake modules to assist in building code

CMake 3 Tools Warning: These tools are being replaced by the Modern CMake. Some of the tools are still being maintained for now, but new projects shou

null 188 Aug 9, 2022