📦 CMake's missing package manager. A small CMake script for setup-free, cross-platform, reproducible dependency management.

Overview

Build Status Actions Status Actions Status Actions Status



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 around CMake's FetchContent module that adds version control, caching, a simple API and more.

Manage everything

Any downloadable project or resource can be added as a version-controlled dependency though CPM, it is not necessary to modify or package anything. Projects using modern CMake are automatically configured and their targets can be used immediately. For everything else, the targets can be created manually after the dependency has been downloaded (see the snippets below for examples).

Further reading

Usage

After CPM.cmake has been added to your project, the function CPMAddPackage or CPMFindPackage can be used to fetch and configure a dependency. Afterwards, any targets defined in the dependency can be used directly. CPMFindPackage and CPMAddPackage take the following named parameters.

CPMAddPackage(
  NAME          # The unique name of the dependency (should be the exported target's name)
  VERSION       # The minimum version of the dependency (optional, defaults to 0)
  OPTIONS       # Configuration options passed to the dependency (optional)
  DOWNLOAD_ONLY # If set, the project is downloaded, but not configured (optional)
  [...]         # Origin parameters forwarded to FetchContent_Declare, see below
)

The origin may be specified by a GIT_REPOSITORY, but other sources, such as direct URLs, are also supported. If GIT_TAG hasn't been explicitly specified it defaults to v(VERSION), a common convention for git projects. On the other hand, if VERSION hasn't been explicitly specified, CPM can automatically identify the version from the git tag in some common cases. GIT_TAG can also be set to a specific commit or a branch name such as master to always download the most recent version. The optional argument FIND_PACKAGE_ARGUMENTS can be specified to a string of parameters that will be passed to find_package if enabled (see below).

If an additional optional parameter EXCLUDE_FROM_ALL is set to a truthy value, then any targets defined inside the dependency won't be built by default. See the CMake docs for details.

A single-argument compact syntax is also supported:

# A git package from a given uri with a version
CPMAddPackage("[email protected]")
# A git package from a given uri with a git tag or commit hash, or branch name
CPMAddPackage("uri#tag")
# A git package with both version and tag provided
CPMAddPackage("[email protected]#tag")

In the shorthand syntax if the URI is of the form gh:user/name, it is interpreted as GitHub URI and converted to https://github.com/user/name.git. If the URI is of the form gl:user/name, it is interpreted as a GitLab URI and coverted to https://gitlab.com/user/name.git. Otherwise the URI used verbatim as a git URL. All packages added using the shorthand syntax will be added using the EXCLUDE_FROM_ALL flag.

The single-argument syntax also works for URLs:

# An archive package from a given url. The version is inferred
CPMAddPackage("https://example.com/my-package-1.2.3.zip")
# An archive package from a given url with an MD5 hash provided
CPMAddPackage("https://example.com/my-package-1.2.3.zip#MD5=68e20f674a48be38d60e129f600faf7d")
# An archive package from a given url. The version is explicitly given
CPMAddPackage("https://example.com/[email protected]")

After calling CPMAddPackage or CPMFindPackage, the following variables are defined in the local scope, where <dependency> is the name of the dependency.

  • <dependency>_SOURCE_DIR is the path to the source of the dependency.
  • <dependency>_BINARY_DIR is the path to the build directory of the dependency.
  • <dependency>_ADDED is set to YES if the dependency has not been added before, otherwise it is set to NO.

The difference between CPMFindPackage and CPMAddPackage is that CPMFindPackage will try to find a local dependency via CMake's find_package and fallback to CPMAddPackage if the dependency is not found. This behaviour can be also modified globally via CPM options.

Full CMakeLists Example

cmake_minimum_required(VERSION 3.14 FATAL_ERROR)

# create project
project(MyProject)

# add executable
add_executable(tests tests.cpp)

# add dependencies
include(cmake/CPM.cmake)
CPMAddPackage("gh:catchorg/[email protected]")

# link dependencies
target_link_libraries(tests Catch2)

See the examples directory for complete examples with source code and check below or in the wiki for example snippets.

Adding CPM

To add CPM to your current project, simply add the latest release of CPM.cmake or get_cpm.cmake to your project's cmake directory. The command below will perform this automatically.

mkdir -p cmake
wget -O cmake/CPM.cmake https://github.com/cpm-cmake/CPM.cmake/releases/latest/download/get_cpm.cmake

You can also download CPM.cmake directly from your project's CMakeLists.txt. See the wiki for more details.

Updating CPM

To update CPM to the newest version, update the script in the project's root directory, for example by running the command above. Dependencies using CPM will automatically use the updated script of the outermost project.

Advantages

  • Small and reusable projects CPM takes care of all project dependencies, allowing developers to focus on creating small, well-tested libraries.
  • Cross-Platform CPM adds projects directly at the configure stage and is compatible with all CMake toolchains and generators.
  • Reproducible builds By versioning dependencies via git commits or tags it is ensured that a project will always be buildable.
  • Recursive dependencies Ensures that no dependency is added twice and all are added in the minimum required version.
  • Plug-and-play No need to install anything. Just add the script to your project and you're good to go.
  • No packaging required Simply add all external sources as a dependency.
  • Simple source distribution CPM makes including projects with source files and dependencies easy, reducing the need for monolithic header files or git submodules.

Limitations

  • No pre-built binaries For every new build directory, all dependencies are initially downloaded and built from scratch. To avoid extra downloads it is recommend to set the CPM_SOURCE_CACHE environmental variable. Using a caching compiler such as ccache can drastically reduce build time.
  • Dependent on good CMakeLists Many libraries do not have CMakeLists that work well for subprojects. Luckily this is slowly changing, however, until then, some manual configuration may be required (see the snippets below for examples). For best practices on preparing projects for CPM, see the wiki.
  • First version used In diamond-shaped dependency graphs (e.g. A depends on C@1.1 and B, which itself depends on C@1.2 the first added dependency will be used (in this case C@1.1). In this case, B requires a newer version of C than A, so CPM will emit a warning. This can be easily resolved by adding a new version of the dependency in the outermost project, or by introducing a package lock file.

For projects with more complex needs and where an extra setup step doesn't matter, it may be worth to check out an external C++ package manager such as vcpkg, conan or hunter. Dependencies added with CPMFindPackage should work with external package managers. Additionally, the option CPM_USE_LOCAL_PACKAGES will enable find_package for all CPM dependencies.

Comparison to FindPackage

The usual way to add libraries in CMake projects is to call find_package(<PackageName>) and to link against libraries defined in a <PackageName>_LIBRARIES variable. While simple, this may lead to unpredictable builds, as it requires the library to be installed on the system and it is unclear which version of the library has been added. Additionally, it is difficult to cross-compile projects (e.g. for mobile), as the dependencies will need to be rebuilt manually for each targeted architecture.

CPM.cmake allows dependencies to be unambiguously defined and builds them from source. Note that the behaviour differs from find_package, as variables exported to the parent scope (such as <PackageName>_LIBRARIES) will not be visible after adding a package using CPM.cmake. The behaviour can be achieved manually, if required.

Comparison to pure FetchContent / ExternalProject

CPM.cmake is a wrapper for CMake's FetchContent module and adds a number of features that turn it into a useful dependency manager. The most notable features are:

  • A simpler to use API
  • Version checking: CPM.cmake will check the version number of any added dependency and omit a warning if another dependency requires a more recent version.
  • Options: any Options passed to a dependency are stored and compared on later use, so if another dependency tries to add an existing dependency with incompatible options a warning will be emitted to the user.
  • Offline builds: CPM.cmake will override CMake's download and update commands, which allows new builds to be configured while offline if all dependencies are available locally.
  • Automatic shallow clone: if a version tag (e.g. v2.2.0) is provided and CPM_SOURCE_CACHE is used, CPM.cmake will perform a shallow clone of the dependency, which should be significantly faster while using less storage than a full clone.
  • Overridable: all CPMAddPackage can be configured to use find_package by setting a CMake flag, making it easy to integrate into projects that may require local versioning through the system's package manager.
  • Package lock files for easier transitive dependency management.
  • Dependencies can be overridden per-build using CMake CLI parameters.

ExternalProject works similarly as FetchContent, however waits with adding dependencies until build time. This has a quite a few disadvantages, especially as it makes using custom toolchains / cross-compiling very difficult and can lead to problems with nested dependencies.

Options

CPM_SOURCE_CACHE

To avoid re-downloading dependencies, CPM has an option CPM_SOURCE_CACHE that can be passed to CMake as -DCPM_SOURCE_CACHE=<path to an external download directory>. This will also allow projects to be configured offline, as long as the dependencies have been added to the cache before. It may also be defined system-wide as an environmental variable, e.g. by exporting CPM_SOURCE_CACHE in your .bashrc or .bash_profile.

export CPM_SOURCE_CACHE=$HOME/.cache/CPM

Note that passing the variable as a configure option to CMake will always override the value set by the environmental variable.

You can use CPM_SOURCE_CACHE on GitHub Actions workflows cache and combine it with ccache, to make your CI faster. See the wiki for more info.

CPM_DOWNLOAD_ALL

If set, CPM will forward all calls to CPMFindPackage as CPMAddPackage. This is useful to create reproducible builds or to determine if the source parameters have all been set correctly. This can also be set as an environmental variable.

CPM_USE_LOCAL_PACKAGES

CPM can be configured to use find_package to search for locally installed dependencies first by setting the CMake option CPM_USE_LOCAL_PACKAGES. If the option CPM_LOCAL_PACKAGES_ONLY is set, CPM will emit an error if the dependency is not found locally. These options can also be set as environmental variables.

Local package override

Library developers are often in the situation where they work on a locally checked out dependency at the same time as on a consumer project. It is possible to override the consumer's dependency with the version by supplying the CMake option CPM_<dependency name>_SOURCE set to the absolute path of the local library. For example, to use the local version of the dependency Dep at the path /path/to/dep, the consumer can be built with the following command.

cmake -Bbuild -DCPM_Dep_SOURCE=/path/to/dep

Package lock

In large projects with many transitive dependencies, it can be useful to introduce a package lock file. This will list all CPM.cmake dependencies and can be used to update dependencies without modifying the original CMakeLists.txt. To use a package lock, add the following line directly after including CPM.cmake.

CPMUsePackageLock(package-lock.cmake)

To create or update the package lock file, build the cpm-update-package-lock target.

cmake -Bbuild
cmake --build build --target cpm-update-package-lock

See the wiki for more info.

Built with CPM.cmake

Some amazing projects that are built using the CPM.cmake package manager. If you know others, feel free to add them here through a PR.

otto-project

OTTO - The Open Source GrooveBox

maphi

Maphi - the Math App

modern-cpp-starter

ModernCppStarter

Snippets

These examples demonstrate how to include some well-known projects with CPM. See the wiki for more snippets.

Catch2

CPMAddPackage("gh:catchorg/[email protected]")

Boost (via boost-cmake)

CPMAddPackage("gh:Orphis/[email protected]")

cxxopts

CPMAddPackage("gh:jarro2783/[email protected]")

Yaml-cpp

CPMAddPackage("gh:jbeder/yaml-cpp#[email protected]")

google/benchmark

CPMAddPackage(
  NAME benchmark
  GITHUB_REPOSITORY google/benchmark
  VERSION 1.5.2
  OPTIONS "BENCHMARK_ENABLE_TESTING Off"
)

if(benchmark_ADDED)
  # enable c++11 to avoid compilation errors
  set_target_properties(benchmark PROPERTIES CXX_STANDARD 11)
endif()

nlohmann/json

CPMAddPackage(
  NAME nlohmann_json
  VERSION 3.6.1
  # the git repo is incredibly large, so we download the archived include directory
  URL https://github.com/nlohmann/json/releases/download/v3.6.1/include.zip
  URL_HASH SHA256=69cc88207ce91347ea530b227ff0776db82dcb8de6704e1a3d74f4841bc651cf
)

if (nlohmann_json_ADDED)
  add_library(nlohmann_json INTERFACE IMPORTED)
  target_include_directories(nlohmann_json INTERFACE ${nlohmann_json_SOURCE_DIR})
endif()

Range-v3

CPMAddPackage(
  NAME range-v3
  URL https://github.com/ericniebler/range-v3/archive/0.5.0.zip
  VERSION 0.5.0
  # the range-v3 CMakeLists screws with configuration options
  DOWNLOAD_ONLY True
)

if(range-v3_ADDED)
  add_library(range-v3 INTERFACE IMPORTED)
  target_include_directories(range-v3 INTERFACE "${range-v3_SOURCE_DIR}/include")
endif()

Lua

CPMAddPackage(
  NAME lua
  GIT_REPOSITORY https://github.com/lua/lua.git
  VERSION 5.3.5
  DOWNLOAD_ONLY YES
)

if (lua_ADDED)
  # lua has no CMake support, so we create our own target

  FILE(GLOB lua_sources ${lua_SOURCE_DIR}/*.c)
  list(REMOVE_ITEM lua_sources "${lua_SOURCE_DIR}/lua.c" "${lua_SOURCE_DIR}/luac.c")
  add_library(lua STATIC ${lua_sources})

  target_include_directories(lua
    PUBLIC
      $<BUILD_INTERFACE:${lua_SOURCE_DIR}>
  )
endif()

For a full example on using CPM to download and configure lua with sol2 see here.

Full Examples

See the examples directory for full examples with source code and check out the wiki for many more example snippets.

Comments
  • Scope package options to avoid changing the local scope

    Scope package options to avoid changing the local scope

    This is the fix for #222, but I found a strange behaviour. Bellow is a test code :

    cmake_minimum_required(VERSION 3.14)
    project(TestOptions)
    
    include("cmake/CPM.cmake")
    
    set(SET "main")
    message(STATUS "From main before set:${SET}, option: ${OPT}")
    
    
    CPMAddPackage(
      NAME titi
      GIT_REPOSITORY https://gitlab.com/flagarde/titi
      GIT_TAG main 
      OPTIONS "OPT ON" "SET YU"
    )
    message(STATUS "From main between set:${SET}, option: ${OPT}")
    
    CPMAddPackage(
      NAME toto
      GIT_REPOSITORY https://gitlab.com/flagarde/toto
      GIT_TAG main 
      OPTIONS "OPT OFF" "SET CHANGE"
    )
    
    message(STATUS "From main after set:${SET}, option: ${OPT}")
    

    First run gives:

    -- The C compiler identification is GNU 10.2.0
    -- The CXX compiler identification is GNU 10.2.0
    -- Detecting C compiler ABI info
    -- Detecting C compiler ABI info - done
    -- Check for working C compiler: /usr/bin/cc - skipped
    -- Detecting C compile features
    -- Detecting C compile features - done
    -- Detecting CXX compiler ABI info
    -- Detecting CXX compiler ABI info - done
    -- Check for working CXX compiler: /usr/bin/c++ - skipped
    -- Detecting CXX compile features
    -- Detecting CXX compile features - done
    -- From main before set:main, option: 
    -- CPM: adding package [email protected] (main)
    -- From titi, set: titi default was "titi" , option: ON default was "FALSE"
    -- From main between set:main, option: 
    -- CPM: adding package [email protected] (main)
    -- From toto, set: CHANGE default was "toto" , option: OFF default was "TRUE"
    -- From main after set:main, option: 
    -- Configuring done
    -- Generating done
    

    -- From titi, set: titi default was "titi" , option: ON default was "FALSE" should be -- From titi, set: YU default was "titi" , option: ON default was "FALSE".

    Second gives the good results :

    -- From main before set:main, option: 
    -- CPM: adding package [email protected] (main)
    -- From titi, set: YU default was "titi" , option: ON default was "FALSE"
    -- From main between set:main, option: 
    -- CPM: adding package [email protected] (main)
    -- From toto, set: CHANGE default was "toto" , option: OFF default was "TRUE"
    -- From main after set:main, option: 
    -- Configuring done
    -- Generating done
    
    opened by flagarde 28
  • Allowing EXCLUDE_FROM_ALL

    Allowing EXCLUDE_FROM_ALL

    Hi @TheLartians ,

    Thanks for the library.

    When I include a CMake library with CPM.cmake it runs all the install commands in that library even when I don't need these installers with my own library.

    When adding the library as a subdirectory, it's possible to use add_subdirectory(libname EXCLUDE_FROM_ALL) to avoid that behavior.

    Is it possible to use EXCLUDE_FROM_ALL when downloading a CMake library?

    I don't know if that's a question or an enhancement.

    Best,

    enhancement 
    opened by alandefreitas 24
  • Parent project options are being cancelled

    Parent project options are being cancelled

    If the parent project has an option that conflicts with the child project, the child project is messing with the scope of the parent project.

    For instance

    message("BUILD_EXAMPLES=${BUILD_EXAMPLES}")
    CPMAddPackage(
            NAME pareto
            GIT_REPOSITORY https://github.com/alandefreitas/pareto.git
            GIT_TAG v1.2.0
            OPTIONS
            "BUILD_MATPLOT_TARGETS OFF"
            "BUILD_EXAMPLES OFF"
    )
    add_executable(spatial_containers spatial_containers.cpp)
    target_link_libraries(spatial_containers PUBLIC pareto)
    message("BUILD_EXAMPLES=${BUILD_EXAMPLES}")
    

    gives me

    BUILD_EXAMPLES=ON
    -- CPM: adding package [email protected] (v1.2.0)
    -- Looking for min
    -- Looking for min - not found
    BUILD_EXAMPLES=OFF
    

    which is a problem because some option names are quite common. Some projects create have prefixes in their options but most projects don't.

    Of course, people can manually do

    set(BUILD_EXAMPLES_PREV ${BUILD_EXAMPLES})
    message("BUILD_EXAMPLES=${BUILD_EXAMPLES}")
    CPMAddPackage(
            NAME pareto
            GIT_REPOSITORY https://github.com/alandefreitas/pareto.git
            GIT_TAG v1.2.0
            OPTIONS
            "BUILD_EXAMPLES OFF"
    )
    add_executable(spatial_containers spatial_containers.cpp)
    target_link_libraries(spatial_containers PUBLIC pareto)
    set(BUILD_EXAMPLES ${BUILD_EXAMPLES_PREV} CACHE BOOL "" FORCE)
    message("BUILD_EXAMPLES=${BUILD_EXAMPLES}")
    

    for all options but that defeats the purpose of the OPTIONS arguments, which is to do what we cannot already do with FetchContent.

    bug 
    opened by alandefreitas 19
  • Confused by the build stage

    Confused by the build stage

    I am wondering if someone could help me understand an issue that I have with the CPM. I can integrated it, no problem. But for some reason, when I build my project. CPM starts to mix up everything. It creates a lib, and bin directory in my build directory and shuffles everything around. I don't exactly know what happened that CPM doesn't put things in their respected -build, -install folders anymore.

    I should probably mention that I'm using the ExternalPackage as well, and direct them to the same _deps directory. But, I don't think that should cause the problem. I feel that somehow, CPM triggers an install target for some reason! I am not sure.

    Thanks for your help in advance!

    opened by amirmasoudabdol 18
  • How to only include public headers?

    How to only include public headers?

    Module in question https://github.com/martell/pthreads-win32.cmake/blob/master/CMakeLists.txt

    This is a cmake adaptation on top of the original pthreads-win32 library. The original library has header/source file in a single directory.

    The cmake adaptation makes proper install targets and move the header/complied libs into the proper location (see below)

    install(TARGETS ${PTHREADS_LIBRARY}
    	RUNTIME DESTINATION ${PTHREADS_BINDIR} COMPONENT ${PTHREADS_BINCOMPONENT}
    	LIBRARY DESTINATION ${PTHREADS_LIBDIR} COMPONENT ${PTHREADS_LIBCOMPONENT}
    	ARCHIVE DESTINATION ${PTHREADS_LIBDIR} COMPONENT ${PTHREADS_LIBCOMPONENT}
    	PUBLIC_HEADER DESTINATION ${PTHREADS_INCLUDEDIR} COMPONENT ${PTHREADS_INCLUDECOMPONENT})
    

    When adding this library using CPMAddPackage(), I needed to do something like target_include_libraries(TARGET INTERFACE <PATH_TO_SOURCE_DIR>) This adds all .h files as include headers, not just the public header.

    My understanding is that CPM does not trigger the "install" step, but just the "configure/build" steps when adding a package.

    Is there anyway to only include the public header?

    Thank you!

    Here's how I am adding that library via CPM

    # ---- pthreads for MSVC-----------
    if(MSVC)
      CPMAddPackage(
              NAME pthreads-win32
              SOURCE_DIR ${PROJECT_SOURCE_DIR}/../../external/pthreads-win32
      )
      print_target_properties(pthreadsVC2)
    endif()
    

    The print_target_properties is a debug function to dump all target properties, its output is:

    Library name of pthreads-win32: pthreadsVC2.
    pthreadsVC2 AUTOGEN_ORIGIN_DEPENDS = ON
    pthreadsVC2 AUTOMOC_COMPILER_PREDEFINES = ON
    pthreadsVC2 AUTOMOC_MACRO_NAMES = Q_OBJECT;Q_GADGET;Q_NAMESPACE
    pthreadsVC2 AUTOMOC_PATH_PREFIX = ON
    pthreadsVC2 BINARY_DIR = C:/Users/justb/Repos/kintek-explorer/cmake-build-debug/_deps/pthreads-win32-build
    pthreadsVC2 BUILD_WITH_INSTALL_RPATH = FALSE
    pthreadsVC2 DEBUG_POSTFIX = d
    pthreadsVC2 IMPORTED = FALSE
    pthreadsVC2 IMPORTED_GLOBAL = FALSE
    pthreadsVC2 INCLUDE_DIRECTORIES = C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32
    pthreadsVC2 INSTALL_NAME_DIR = @executable_path/../lib
    pthreadsVC2 INSTALL_RPATH = $ORIGIN/../lib
    pthreadsVC2 INSTALL_RPATH_USE_LINK_PATH = TRUE
    pthreadsVC2 NAME = pthreadsVC2
    pthreadsVC2 POSITION_INDEPENDENT_CODE = True
    pthreadsVC2 PUBLIC_HEADER = C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/pthread.h;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/sched.h;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/semaphore.h
    pthreadsVC2 SKIP_BUILD_RPATH = FALSE
    pthreadsVC2 SOURCES = C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/attr.c;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/barrier.c;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/cancel.c;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/cleanup.c;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/condvar.c;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/create.c;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/dll.c;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/autostatic.c;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/errno.c;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/exit.c;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/fork.c;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/global.c;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/misc.c;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/mutex.c;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/nonportable.c;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/private.c;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/rwlock.c;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/sched.c;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/semaphore.c;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/signal.c;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/spin.c;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/sync.c;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/tsd.c;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/pthread.h;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/sched.h;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/semaphore.h;C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32/pthreads-win32/version.rc
    pthreadsVC2 SOURCE_DIR = C:/Users/justb/Repos/kintek-explorer/external/pthreads-win32
    pthreadsVC2 TYPE = SHARED_LIBRARY
    pthreadsVC2 UNITY_BUILD_BATCH_SIZE = 8 
    
    enhancement help desk 
    opened by bolu-atx 17
  • Unknown CMake command

    Unknown CMake command "CPMAddPackage"

    Hi, I'm facing this problem when reloading the CMake configuration on CLion.

    Unknown CMake command "CPMAddPackage"

    The problem disappears if I remove the checks that starts with if(CPM_DIRECTORY) in the CPM.cmake. What I can tell you is that it comes from the CMakeCache.txt, there's probably a cached option that is preventing your script from going on and declare the functions needed.

    Tried with both the bundled CMake 3.17 that the latest CMake binaries (3.19+).

    opened by NicholasBertazzon 15
  • Trouble linking crossplatform library 🙏

    Trouble linking crossplatform library 🙏

    Full reproduction: https://github.com/developer239/test_cpm Repository that I can't link: https://github.com/smasherprog/screen_capture_lite

    # CMAkeList.txt
    
    cmake_minimum_required(VERSION 3.19)
    project(test_cpm)
    
    set(CMAKE_CXX_STANDARD 14)
    
    # CPM
    set(CPM_DOWNLOAD_VERSION 0.27.2)
    set(CPM_DOWNLOAD_LOCATION "${CMAKE_BINARY_DIR}/cmake/CPM_${CPM_DOWNLOAD_VERSION}.cmake")
    
    if(NOT (EXISTS ${CPM_DOWNLOAD_LOCATION}))
        message(STATUS "Downloading CPM.cmake")
        file(DOWNLOAD https://github.com/TheLartians/CPM.cmake/releases/download/v${CPM_DOWNLOAD_VERSION}/CPM.cmake ${CPM_DOWNLOAD_LOCATION})
    endif()
    
    include(${CPM_DOWNLOAD_LOCATION})
    
    # EXECUTABLES
    
    add_executable(test_cpm main.cpp)
    
    # DEPENDENCIES
    
    CPMAddPackage(NAME spdlog GITHUB_REPOSITORY gabime/spdlog VERSION 1.7.0)
    
    CPMAddPackage(
            NAME Screen_Capture
            GITHUB_REPOSITORY smasherprog/screen_capture_lite
            GIT_TAG 17.0.3
    )
    
    target_link_libraries(test_cpm spdlog Screen_Capture)
    
    # main.cpp
    
    #include <spdlog/spdlog.h>
    #include <Screen_Capture.h>
    
    int main() {
        spdlog::info("Hello world!");
        return 0;
    }
    

    Log:

    Maybe I misunderstood how does the linking work? 🤔 I had very similar problem with opencv.

    fatal error: 'Screen_Capture.h' file not found
    #include <Screen_Capture.h>
    

    image

    opened by developer239 13
  • Timestamps for URL downloads match the download time

    Timestamps for URL downloads match the download time

    By enabling CMake policy 135 we ensure that extracted files timestamp match that of the download time, instead of when the archive is created. This makes sure that if the URL changes to an older version we still rebuild everything as the timestamp stays newer.

    opened by robertmaynard 10
  • Setting CPM_SOURCE_ROOT from the environment

    Setting CPM_SOURCE_ROOT from the environment

    I use similar dependencies for various project, so that new feature would help me a lot. Is there a way to setup an environment variable for it? I would set CPM_SOURCE_ROOT per machine/user not per project. I would point in to $HOME/.cache/CPM or similar

    enhancement 
    opened by aggsol 10
  • Weird issue with CPM_SOURCE_CACHE and FetchContent

    Weird issue with CPM_SOURCE_CACHE and FetchContent

    In the top-level project there is https://github.com/vtil-project/VTIL-Utils/blob/master/cmake/VTIL-Core.cmake:

    CPMAddPackage(
        NAME VTIL-Core
        GIT_REPOSITORY https://github.com/mrexodia/VTIL-Core
        GIT_TAG e6debb384cb218caff8cb94f50f00076b994a762
    )
    

    And after that it includes https://github.com/vtil-project/VTIL-Utils/blob/master/cmake/VTIL-NativeLifters.cmake:

    CPMAddPackage(
        NAME VTIL-NativeLifters
        GIT_REPOSITORY https://github.com/vtil-project/VTIL-NativeLifters
        GIT_TAG f8837ef4d2412a5a1c25f725f25685a23e1cf1a1
    )
    

    Inside the VTIL-NativeLifters repo there is a FetchContent call with the name VTIL-Core, The idea here is that you can pin a different version of VTIL-Core in your project that will then be used to compile the VTIL-NativeLifters library.

    https://github.com/vtil-project/VTIL-NativeLifters/blob/master/Dependencies/CMakeLists.txt#L4:

    include(FetchContent)
    
    message(STATUS "Fetching VTIL-Core (this might take a while)...")
    FetchContent_Declare(
        VTIL-Core
        GIT_REPOSITORY https://github.com/vtil-project/VTIL-Core
        GIT_TAG        eeffb26b8b9ef7b4bd6ffbfc09f3133b70b36eda
        GIT_SHALLOW    false
    )
    FetchContent_MakeAvailable(VTIL-Core)
    

    When using CPM_SOURCE_CACHE CMake errors out:

    D:\CodeBlocks\VTIL-Utils\build>cmake ..
    -- Building for: Visual Studio 16 2019
    -- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19042.
    -- The C compiler identification is MSVC 19.29.30038.1
    -- The CXX compiler identification is MSVC 19.29.30038.1
    -- Detecting C compiler ABI info
    -- Detecting C compiler ABI info - done
    -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30037/bin/Hostx64/x64/cl.exe - skipped
    -- Detecting C compile features
    -- Detecting C compile features - done
    -- Detecting CXX compiler ABI info
    -- Detecting CXX compiler ABI info - done
    -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30037/bin/Hostx64/x64/cl.exe - skipped
    -- Detecting CXX compile features
    -- Detecting CXX compile features - done
    -- Fetching capstone (this might take a while)...
    CMake Deprecation Warning at build/_deps/capstone-src/CMakeLists.txt:1 (cmake_minimum_required):
      Compatibility with CMake < 2.8.12 will be removed from a future version of
      CMake.
    
      Update the VERSION argument <min> value or use a ...<max> suffix to tell
      CMake that the project does not need compatibility with older versions.
    
    
    CMake Deprecation Warning at build/_deps/capstone-src/CMakeLists.txt:18 (cmake_policy):
      The OLD behavior for policy CMP0048 will be removed from a future version
      of CMake.
    
      The cmake-policies(7) manual explains that the OLD behaviors of all
      policies are deprecated and that a policy should be set to OLD only under
      specific short-term circumstances.  Projects should be ported to the NEW
      behavior and not rely on setting a policy to OLD.
    
    
    Enabling CAPSTONE_ARM_SUPPORT
    Enabling CAPSTONE_ARM64_SUPPORT
    Enabling CAPSTONE_M68K_SUPPORT
    Enabling CAPSTONE_MIPS_SUPPORT
    Enabling CAPSTONE_PPC_SUPPORT
    Enabling CAPSTONE_SPARC_SUPPORT
    Enabling CAPSTONE_SYSZ_SUPPORT
    Enabling CAPSTONE_XCORE_SUPPORT
    Enabling CAPSTONE_X86_SUPPORT
    Enabling CAPSTONE_TMS320C64X_SUPPORT
    Enabling CAPSTONE_M680X_SUPPORT
    Enabling CAPSTONE_EVM_SUPPORT
    Enabling CAPSTONE_MOS65XX_SUPPORT
    -- Fetching keystone (this might take a while)...
    -- Looking for pthread.h
    -- Looking for pthread.h - not found
    -- Found Threads: TRUE
    -- CPM: adding package [email protected] (e6debb384cb218caff8cb94f50f00076b994a762 at d:/cpm_cache/vtil-core/b00df6cc2b142d6fa5bce7908fa7339da177c741)
    -- Fetching VTIL-Core (this might take a while)...
    CMake Error at C:/Program Files/CMake/share/cmake-3.20/Modules/FetchContent.cmake:1206 (add_subdirectory):
      The binary directory
    
        D:/CodeBlocks/VTIL-Utils/build/_deps/vtil-core-build
    
      is already used to build a source directory.  It cannot be used to build
      source directory
    
        D:/CodeBlocks/VTIL-Utils/build/_deps/vtil-core-src
    
      Specify a unique binary directory name.
    Call Stack (most recent call first):
      D:/cpm_cache/vtil-nativelifters/b0b7a3915a18707147fb220d4cf2d2f76e9d8d8d/Dependencies/CMakeLists.txt:10 (FetchContent_MakeAvailable)
    
    
    -- CPM: adding package [email protected] (f8837ef4d2412a5a1c25f725f25685a23e1cf1a1 at d:/cpm_cache/vtil-nativelifters/b0b7a3915a18707147fb220d4cf2d2f76e9d8d8d)
    -- CPM: adding package [email protected] (ae22269df734a2b0957a9ab4e37be41f61866dbe at d:/cpm_cache/args/0fef5c19d6fb87e7b5acefd2362b022afaf2dab6)
    -- CPM: adding package [email protected] (v0.0.5 at d:/cpm_cache/cpmlicenses.cmake/2e9893c848f8cf158d41d1c4737a276bac779ef3)
    -- Configuring incomplete, errors occurred!
    See also "D:/CodeBlocks/VTIL-Utils/build/CMakeFiles/CMakeOutput.log".
    See also "D:/CodeBlocks/VTIL-Utils/build/CMakeFiles/CMakeError.log".
    

    Without CPM_SOURCE_CACHE everything works as intended:

    D:\CodeBlocks\VTIL-Utils\build>cmake ..
    -- Building for: Visual Studio 16 2019
    -- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19042.
    -- The C compiler identification is MSVC 19.29.30038.1
    -- The CXX compiler identification is MSVC 19.29.30038.1
    -- Detecting C compiler ABI info
    -- Detecting C compiler ABI info - done
    -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30037/bin/Hostx64/x64/cl.exe - skipped
    -- Detecting C compile features
    -- Detecting C compile features - done
    -- Detecting CXX compiler ABI info
    -- Detecting CXX compiler ABI info - done
    -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30037/bin/Hostx64/x64/cl.exe - skipped
    -- Detecting CXX compile features
    -- Detecting CXX compile features - done
    -- CPM: adding package [email protected] (e6debb384cb218caff8cb94f50f00076b994a762)
    -- Fetching capstone (this might take a while)...
    CMake Deprecation Warning at build/_deps/capstone-src/CMakeLists.txt:1 (cmake_minimum_required):
      Compatibility with CMake < 2.8.12 will be removed from a future version of
      CMake.
    
      Update the VERSION argument <min> value or use a ...<max> suffix to tell
      CMake that the project does not need compatibility with older versions.
    
    
    CMake Deprecation Warning at build/_deps/capstone-src/CMakeLists.txt:18 (cmake_policy):
      The OLD behavior for policy CMP0048 will be removed from a future version
      of CMake.
    
      The cmake-policies(7) manual explains that the OLD behaviors of all
      policies are deprecated and that a policy should be set to OLD only under
      specific short-term circumstances.  Projects should be ported to the NEW
      behavior and not rely on setting a policy to OLD.
    
    
    Enabling CAPSTONE_ARM_SUPPORT
    Enabling CAPSTONE_ARM64_SUPPORT
    Enabling CAPSTONE_M68K_SUPPORT
    Enabling CAPSTONE_MIPS_SUPPORT
    Enabling CAPSTONE_PPC_SUPPORT
    Enabling CAPSTONE_SPARC_SUPPORT
    Enabling CAPSTONE_SYSZ_SUPPORT
    Enabling CAPSTONE_XCORE_SUPPORT
    Enabling CAPSTONE_X86_SUPPORT
    Enabling CAPSTONE_TMS320C64X_SUPPORT
    Enabling CAPSTONE_M680X_SUPPORT
    Enabling CAPSTONE_EVM_SUPPORT
    Enabling CAPSTONE_MOS65XX_SUPPORT
    -- Fetching keystone (this might take a while)...
    -- Looking for pthread.h
    -- Looking for pthread.h - not found
    -- Found Threads: TRUE
    -- CPM: adding package [email protected] (f8837ef4d2412a5a1c25f725f25685a23e1cf1a1)
    -- Fetching VTIL-Core (this might take a while)...
    -- CPM: adding package [email protected] (ae22269df734a2b0957a9ab4e37be41f61866dbe)
    -- CPM: adding package [email protected] (v0.0.5)
    -- Configuring done
    -- Generating done
    -- Build files have been written to: D:/CodeBlocks/VTIL-Utils/build
    

    This is cmake 3.20.5 btw

    opened by mrexodia 9
  • find_package and CPMFindPackage have different behaviors

    find_package and CPMFindPackage have different behaviors

    Hello,

    I'm using CPMFindPackage() to check for a dependency on CMocka and noticing some strange behavior with the find_package portion. Do you know what I might be doing wrong here?

    CPMFindPackage(
      NAME CMOCKA
      GIT_REPOSITORY https://git.cryptomilk.org/projects/cmocka.git/
      VERSION 1.1.5
      GIT_TAG cmocka-1.1.5
      OPTIONS
        "WITH_EXAMPLES OFF"
    )
    
    message("CMOCKA_FOUND: ${CMOCKA_FOUND}")
    message("CMOCKA_ADDED: ${CMOCKA_ADDED}")
    message("CMOCKA_INCLUDES: ${CMOCKA_INCLUDE_DIR}")
    message("CMOCKA_LIBRARIES: ${CMOCKA_LIBRARIES}")
    

    The library is installed on my system with a CMake config file. I see this output from CPM, but the FOUND/ADDED variables are not set, and the other variables defined by the config file aren't used.

    -- CPM: using local package [email protected]
    CMOCKA_FOUND:
    CMOCKA_ADDED:
    CMOCKA_INCLUDES:
    CMOCKA_LIBRARIES:
    

    If I remove CPMFindPackage and add find_package:

    find_package(CMOCKA)
    

    This time, CMOCKA_FOUND will be defined, and the values defined by the config file are used.

    CMOCKA_FOUND: 1
    CMOCKA_ADDED:
    CMOCKA_INCLUDES: /usr/local/include
    CMOCKA_LIBRARIES: /usr/local/lib/libcmocka.dylib
    
    documentation 
    opened by phillipjohnston 9
  • With vcpkg stack overflow

    With vcpkg stack overflow

    I used -DCMAKE_TOOLCHAIN_FILE=/Users/apple/vcpkg/scripts/buildsystems/vcpkg.cmake

    CMakeLists.txt add find_package(OpenSSL REQUIRED) will stack overflow

      /Users/apple/vcpkg/installed/arm64-osx/share/openssl/vcpkg-cmake-wrapper.cmake:37 (_find_package)
      /Users/apple/vcpkg/scripts/buildsystems/vcpkg.cmake:788 (include)
      /Users/apple/vcpkg/installed/arm64-osx/share/openssl/vcpkg-cmake-wrapper.cmake:37 (_find_package)
      /Users/apple/vcpkg/scripts/buildsystems/vcpkg.cmake:788 (include)
      /Users/apple/vcpkg/installed/arm64-osx/share/openssl/vcpkg-cmake-wrapper.cmake:37 (_find_package)
      /Users/apple/vcpkg/scripts/buildsystems/vcpkg.cmake:788 (include)
      /Users/apple/vcpkg/installed/arm64-osx/share/openssl/vcpkg-cmake-wrapper.cmake:37 (_find_package)
      /Users/apple/vcpkg/scripts/buildsystems/vcpkg.cmake:788 (include)
      /Users/apple/vcpkg/installed/arm64-osx/share/openssl/vcpkg-cmake-wrapper.cmake:37 (_find_package)
      /Users/apple/vcpkg/scripts/buildsystems/vcpkg.cmake:788 (include)
      /Users/apple/vcpkg/installed/arm64-osx/share/openssl/vcpkg-cmake-wrapper.cmake:37 (_find_package)
      /Users/apple/vcpkg/scripts/buildsystems/vcpkg.cmake:788 (include)
      /Users/apple/vcpkg/installed/arm64-osx/share/openssl/vcpkg-cmake-wrapper.cmake:37 (_find_package)
      /Users/apple/vcpkg/scripts/buildsystems/vcpkg.cmake:788 (include)
      /Users/apple/vcpkg/installed/arm64-osx/share/openssl/vcpkg-cmake-wrapper.cmake:37 (_find_package)
      /Users/apple/vcpkg/scripts/buildsystems/vcpkg.cmake:788 (include)
      /Users/apple/vcpkg/installed/arm64-osx/share/openssl/vcpkg-cmake-wrapper.cmake:37 (_find_package)
      /Users/apple/vcpkg/scripts/buildsystems/vcpkg.cmake:788 (include)
      /Users/apple/vcpkg/installed/arm64-osx/share/openssl/vcpkg-cmake-wrapper.cmake:37 (_find_package)
      /Users/apple/vcpkg/scripts/buildsystems/vcpkg.cmake:788 (include)
      CMakeLists.txt:35 (find_package)
    

    I don't known the bug is the CPM or Vcpkg

    opened by fesily 1
  • How to skip `cpm_check_git_working_dir_is_clean`

    How to skip `cpm_check_git_working_dir_is_clean`

    Hi, when benchmarking cmake run with cmake --profiling-format=google-trace --profiling-output=perf.json .. I find that some huge repo takes couple of hundred of milliseconds to run cpm_check_git_working_dir_is_clean. I would like to be able to skip this check.

    I see in source code: https://github.com/cpm-cmake/CPM.cmake/blob/03705fcce165c7eb2680e4c7d8a272cfb0a1061a/cmake/CPM.cmake#L715-L721

    It seems to be possible to skip it by adding PATCH_COMMAND, but this is per target. Is there any other way I've missed to disable the check? Ideally some -DCPM_CHECK_GIT_WORKING_DIR_IS_CLEAN=OFF that I can apply everywhere. I would be happy to provide a PR, but I guess some discussion on how to do things is therefore required.

    Here is also an example of benchmark: image

    As you can see, it's not lots of time, but when there is 20-30 projects, it can takes couple of seconds.

    Have a nice day.

    opened by OlivierLDff 1
  • Any idea about how to resolve target name clash?

    Any idea about how to resolve target name clash?

    Hi there,

    I'm using CPM as the dependency manager of my project so far, and it works pretty well. However, I'm facing a problem about target name clashing right now.

    My projects uses Abseil-cpp (from Google) as a basic C++ library and Gperftools (also from Google) as the profiler. The problem is that they both have a target named "stacktrace" introduced by add_library. As CPM using add_subdirectory under the hood, this will cause the CMake to complain about target naming conflict.

    Any idea about how to resolve the issue without patching those third-parties? Thank you!

    opened by MrJia1997 3
  • Example for xxhash

    Example for xxhash

    I am trying to bring in xxhash with CPM (0.32) but I can't figure it out.

    xxhash has an un-official cmake support, with a subfolder, that I got to work in the past with the SOURCE_SUBDIR magic value. Is SOURCE_SUBDIR supported with CPM ?

    I am also trying to do it the DOWNLOAD_ONLY way, and then create a header only library.

    cpmaddpackage(
      NAME
      xxhash
      GITHUB_REPOSITORY
      "Cyan4973/xxhash"
      OPTIONS
      ""
      VERSION
      ${xxhash_version}
      DOWNLOAD_ONLY
      YES)
    
    if(xxhash_ADDED)
      add_library(xxhash INTERFACE)
      target_sources(xxhash INTERFACE ${xxhash_SOURCE_DIR}/xxhash.h ${xxhash_SOURCE_DIR}/xxh3.h)
      
      packageproject(...)
    endif()
    

    But I get lots of errors later on. I also tried to add target_include_directories but I get similar errors.

    CMake Error in CMakeLists.txt:
      Target "xxhash" INTERFACE_SOURCES property contains path:
    
        "/Users/benjamin.sergeant/projects/xyz/build/_deps/xxhash-src/xxh3.h"
    
      which is prefixed in the build directory.
    
    opened by bsergean 2
  • CPM should implement as a

    CPM should implement as a "Dependency Provider" as of CMake v3.24

    https://cmake.org/cmake/help/latest/command/cmake_language.html#dependency-providers

    This relates to existing topics:

    • https://github.com/cpm-cmake/CPM.cmake/issues/404
    • https://github.com/cpm-cmake/CPM.cmake/issues/414

    The general workflow would in 'theory' require that Declare must be done by the user:

    CPMDeclarePackage( Foo ... ) # Foo registered as available package in user-cmake or package-lock etc
    find_package(Foo)                  # Foo calls into CPM to fetch Foo
    
    opened by CraigHutchinson 0
  • Rework CPM Package functions

    Rework CPM Package functions

    This is a proposal to clean-up and rework the package functions. The goals of this are more or less to allow several future features. The future features are to be more clearly defined, but the idea is basically this:

    • Allow inferring packages from targets as per #404
    • First steps towards allowing package repositories (allowing code like CPMAddPackage(p:Catch2) in a yet more distant future)

    Current status

    We have:

    • CPMDeclarePackage(name definition) - this is a super fast function which only stores the definition for a named package in memory, or, more precisely, associates name with definition even if the definition doesn't match the name. It does not parse or do anything with the definition.
    • CPMAddPackage - supports various combination of arguments including a shorthand syntax and tries to infer missing ones from the ones which are available or from ones provided as a definition to CPMDeclarePackage. Leads to a download.
    • CPMFindPackage - tries to find a package with CMake's find_package and falls back to CPMAddPackage if not found locally. The arguments to this function are special, and do not match the ones CPMAddPackage (for example the shorthand syntax is not supported)

    Problems

    • Package metadata (provided via arguments like the ones in CPMAddPackage) is not available unless a download happens. Metadata is important if we want to automatically add packages based on it
    • Parsing metadata is from CPMDeclarePackage is impractical because not all declared packages can be added. This is even more of an issue in a hypothetical future with package repositories which might have thousands of declare packages
    • While the shorthand syntax is pleasant it's sometimes not enough, and it's also not available to CPMFindPackage (#219)
    • Metadata is only provided once. One can't provide it with multiple calls (like the ones for CMake targets)

    Proposed solution

    1. Have a formal package lifecycle:

    1. declared - Only the package name is known and it may be associated with an unparsed definition
    2. defined - The metadata for the package is known (parsed and stored in memory), but a download has not happened yet
    3. added - The package is downloaded and add_subdirectory has been called (unless DOWNLOAD_ONLY is true) We can't practically allow a separation between those two phases.

    2. Add new package functions:

    • CPMUsePackage(name) - parse the metadata for a declared package. Error if the package is not declared
    • CPMDefinePackage(definition) - roughly a declare+use in one. Defines data and parses it

    After these two a package is defined, but not added.

    Thus CPMAddPackage implicitly defines it

    3. Allow explicit shorthand definition:

    CPMAddPackage(DEF gh:foo/[email protected] OPTIONS "FOOBAR_TESTS OFF")

    4. Allow the same arguments to package functions

    These arguments are "definition". Allowed in CPMDefinePackage CPMAddPackage and CPMFindPackage. Thus code like CPMFindPackage(gh:myorg/[email protected]) would internally try find_package(OpenSSL) as "OpenSSL" can be parsed from the definition

    Now, with the listed changes so far CPMFindPackage is an outlier. We cannot define or declare a package for which find_package is attempted. So:

    5. Allow a find_package request in package definitions

    This means a new boolean argument in definitions TRY_FIND_PACKAGE. Allow FIND_PACKAGE_ARGUMENTS in all definitions.

    Thus CPMFindPackage becomes equivalent to CPMAddPackage(${ARGN} TRY_FIND_PACKAGE TRUE)

    With the changes so far the explicit transition from declared to defined is CPMUsePackage(name) and the explicit transition from defined to added is CPMAddPackage(NAME name), though it can also be a transition from declared directly to added. First, to match the shorthand style:

    6. Allow a name-only shorthand for CPMAddPackage

    CPMAddPackage(p:name) - will add the package if declared or defined, and produce an error if neither is true

    From a usability perspective there seems to be no need for a function that will add a package and produce an error if it's not defined, but it may be an optimization to do so. So I also propose adding one:

    7. CPMEnablePackage(name)

    opened by iboB 0
Releases(v0.36.0)
  • v0.36.0(Oct 4, 2022)

    What's Changed

    • Fix: CPMFmtExample by @AlessandroW in https://github.com/cpm-cmake/CPM.cmake/pull/410
    • Updated contributor list by @iboB in https://github.com/cpm-cmake/CPM.cmake/pull/411
    • Add CONTRIBUTING.md by @TheLartians in https://github.com/cpm-cmake/CPM.cmake/pull/412
    • Update example in readme by @TheLartians in https://github.com/cpm-cmake/CPM.cmake/pull/413
    • Added export of CPM_LAST_PACKAGE_NAME by @CraigHutchinson in https://github.com/cpm-cmake/CPM.cmake/pull/403

    New Contributors

    • @AlessandroW made their first contribution in https://github.com/cpm-cmake/CPM.cmake/pull/410
    • @CraigHutchinson made their first contribution in https://github.com/cpm-cmake/CPM.cmake/pull/403

    Full Changelog: https://github.com/cpm-cmake/CPM.cmake/compare/v0.35.6...v0.36.0

    Source code(tar.gz)
    Source code(zip)
    CPM.cmake(34.37 KB)
    get_cpm.cmake(851 bytes)
  • v0.35.6(Sep 13, 2022)

    What's Changed

    • cpm_find_package Use found package version when possible by @robertmaynard in https://github.com/cpm-cmake/CPM.cmake/pull/396
    • Expand absolute path later in get_cpm.cmake by @kisielk in https://github.com/cpm-cmake/CPM.cmake/pull/397
    • Don't warn about dirty source trees when a PATCH_COMMAND is provided by @robertmaynard in https://github.com/cpm-cmake/CPM.cmake/pull/401

    New Contributors

    • @kisielk made their first contribution in https://github.com/cpm-cmake/CPM.cmake/pull/397

    Full Changelog: https://github.com/cpm-cmake/CPM.cmake/compare/v0.35.5...v0.35.6

    Source code(tar.gz)
    Source code(zip)
    CPM.cmake(34.31 KB)
    get_cpm.cmake(851 bytes)
  • v0.35.5(Aug 11, 2022)

    What's Changed

    • Document policies being set to NEW when including CPM.cmake by @iboB in https://github.com/cpm-cmake/CPM.cmake/pull/383
    • Fix a very confusing typo (CMP.cmake -> CPM.cmake) by @OlivierLDff in https://github.com/cpm-cmake/CPM.cmake/pull/384
    • Perform policy changes only in top-level CPM.cmake script by @TheLartians in https://github.com/cpm-cmake/CPM.cmake/pull/386
    • Restore policy changes in CPMAddPackage by @robertmaynard in https://github.com/cpm-cmake/CPM.cmake/pull/388

    Full Changelog: https://github.com/cpm-cmake/CPM.cmake/compare/v0.35.4...v0.35.5

    Source code(tar.gz)
    Source code(zip)
    CPM.cmake(34.15 KB)
    get_cpm.cmake(845 bytes)
  • v0.35.4(Aug 3, 2022)

    What's Changed

    • Add Methane Kit project to showcase table in ReadMe by @egorodet in https://github.com/cpm-cmake/CPM.cmake/pull/380
    • Use 3 column layout in showcase by @TheLartians in https://github.com/cpm-cmake/CPM.cmake/pull/381
    • Timestamps for URL downloads match the download time by @robertmaynard in https://github.com/cpm-cmake/CPM.cmake/pull/372

    New Contributors

    • @egorodet made their first contribution in https://github.com/cpm-cmake/CPM.cmake/pull/380

    Full Changelog: https://github.com/cpm-cmake/CPM.cmake/compare/v0.35.3...v0.35.4

    Source code(tar.gz)
    Source code(zip)
    CPM.cmake(34.05 KB)
    get_cpm.cmake(845 bytes)
  • v0.35.3(Jul 31, 2022)

  • v0.35.2(Jul 26, 2022)

    What's Changed

    • Add readme "Customize repository URL" with git-config by @OlivierLDff in https://github.com/cpm-cmake/CPM.cmake/pull/353
    • Klogg switched to CPM for dependency management by @variar in https://github.com/cpm-cmake/CPM.cmake/pull/363
    • bump example range-v3 to 0.12.0 by @david-fong in https://github.com/cpm-cmake/CPM.cmake/pull/366
    • CPMAddPackage fails if the SOURCE_DIR directory is deleted. by @thomas-mp in https://github.com/cpm-cmake/CPM.cmake/pull/370

    New Contributors

    • @variar made their first contribution in https://github.com/cpm-cmake/CPM.cmake/pull/363
    • @david-fong made their first contribution in https://github.com/cpm-cmake/CPM.cmake/pull/366
    • @thomas-mp made their first contribution in https://github.com/cpm-cmake/CPM.cmake/pull/370

    Full Changelog: https://github.com/cpm-cmake/CPM.cmake/compare/v0.35.1...v0.35.2

    Source code(tar.gz)
    Source code(zip)
    CPM.cmake(33.77 KB)
    get_cpm.cmake(845 bytes)
  • v0.35.1(May 16, 2022)

    What's Changed

    • Add liblava to "Built with CPM.cmake" by @TheLavaBlock in https://github.com/cpm-cmake/CPM.cmake/pull/346
    • Allow overriding FetchContent using CPM by @TheLartians in https://github.com/cpm-cmake/CPM.cmake/pull/352

    New Contributors

    • @TheLavaBlock made their first contribution in https://github.com/cpm-cmake/CPM.cmake/pull/346

    Full Changelog: https://github.com/cpm-cmake/CPM.cmake/compare/v0.35.0...v0.35.1

    Source code(tar.gz)
    Source code(zip)
    CPM.cmake(33.15 KB)
    get_cpm.cmake(845 bytes)
  • v0.35.0(Feb 11, 2022)

    What's Changed

    • Fix comment out-of-sync with modified code by @danra in https://github.com/cpm-cmake/CPM.cmake/pull/321
    • Unified GitHub workflow for tests on major operating systems by @iboB in https://github.com/cpm-cmake/CPM.cmake/pull/326
    • [Example] Disable JSON tests being included in ctest by @Vinpasso in https://github.com/cpm-cmake/CPM.cmake/pull/329
    • Remove badges from readme by @TheLartians in https://github.com/cpm-cmake/CPM.cmake/pull/327
    • Initial version of integration tests by @iboB in https://github.com/cpm-cmake/CPM.cmake/pull/330
    • Allows set/set(CACHE) to behave the same as set(X)/option(x) by @robertmaynard in https://github.com/cpm-cmake/CPM.cmake/pull/335
    • Use CMake 3.14+ documented way to pass the source dir -S. by @robertmaynard in https://github.com/cpm-cmake/CPM.cmake/pull/337
    • Fix beginner’s trap / fix broken example for nlohmann/json by @Tobi823 in https://github.com/cpm-cmake/CPM.cmake/pull/338
    • List of contributors by @iboB in https://github.com/cpm-cmake/CPM.cmake/pull/340
    • Some typo fixes. by @bilke in https://github.com/cpm-cmake/CPM.cmake/pull/341
    • Add per package CPM_DOWNLOAD controls by @robertmaynard in https://github.com/cpm-cmake/CPM.cmake/pull/336

    New Contributors

    • @danra made their first contribution in https://github.com/cpm-cmake/CPM.cmake/pull/321
    • @Vinpasso made their first contribution in https://github.com/cpm-cmake/CPM.cmake/pull/329
    • @robertmaynard made their first contribution in https://github.com/cpm-cmake/CPM.cmake/pull/335
    • @Tobi823 made their first contribution in https://github.com/cpm-cmake/CPM.cmake/pull/338
    • @bilke made their first contribution in https://github.com/cpm-cmake/CPM.cmake/pull/341

    Full Changelog: https://github.com/cpm-cmake/CPM.cmake/compare/v0.34.3...v0.35.0

    Thanks to everyone who contributed for these updates!

    Source code(tar.gz)
    Source code(zip)
    CPM.cmake(31.21 KB)
    get_cpm.cmake(845 bytes)
  • v0.34.3(Dec 30, 2021)

  • v0.34.2(Dec 15, 2021)

  • v0.34.1(Dec 5, 2021)

  • v0.34.0(Sep 15, 2021)

  • v0.33.0(Sep 15, 2021)

  • v0.32.3(Aug 29, 2021)

  • v0.32.2(Jun 8, 2021)

  • v0.32.1(Apr 16, 2021)

  • v0.32.0(Mar 25, 2021)

    Previously, function passed to a dependency were stored in the CMake cache. Following version 0.32.0, options are now scoped to the dependency and not leaked into the parent or CMake cache. This could potentially break projects, if relied on options entering the cache, however we assume that the change leads to a more predictable behaviour for almost all use cases. See #222 for a detailed discussion.

    Additionally, the change means that we cannot (easily) check for option consistency, so the check has been disabled for now and is planned to be re-implemented in a further update.

    Source code(tar.gz)
    Source code(zip)
    CPM.cmake(27.12 KB)
    get_cpm.cmake(845 bytes)
  • v0.31.2(Mar 25, 2021)

  • v0.31.1(Feb 23, 2021)

  • v0.31.0(Feb 22, 2021)

  • v0.30.0(Feb 17, 2021)

  • v0.29.0(Feb 16, 2021)

    This adds an optional parameter EXCLUDE_FROM_ALL that prevents packages from leaking unwanted targets (such as tests, examples) to CPM.cmake projects. See #152 and #198 for details.

    Usage example

    CPMAddPackage(
      NAME googletest
      GITHUB_REPOSITORY google/googletest
      VERSION 1.8.0
      GIT_TAG release-1.8.0
      # prevent googletest targets from leaking into all
      EXCLUDE_FROM_ALL YES
    )
    
    Source code(tar.gz)
    Source code(zip)
    CPM.cmake(21.31 KB)
    get_cpm.cmake(845 bytes)
  • v0.29.0-preview-4(Feb 15, 2021)

  • v0.29.0-preview-2(Feb 15, 2021)

  • v0.28.4(Feb 8, 2021)

  • v0.28.3(Feb 7, 2021)

  • v0.28.2(Jan 27, 2021)

    The package lock output is now prettified.

    Before

    # cxxopts
    CPMDeclarePackage(cxxopts "NAME;cxxopts;VERSION;2.2.0;GITHUB_REPOSITORY;jarro2783/cxxopts;OPTIONS;CXXOPTS_BUILD_EXAMPLES Off;CXXOPTS_BUILD_TESTS Off")
    

    After

    # cxxopts
    CPMDeclarePackage(cxxopts
      NAME cxxopts
      VERSION 2.2.0
      GITHUB_REPOSITORY jarro2783/cxxopts
      OPTIONS
        "CXXOPTS_BUILD_EXAMPLES Off"
        "CXXOPTS_BUILD_TESTS Off"
    )
    

    Thanks to @alexandreSalconiDenis for the suggestion and PR!

    Source code(tar.gz)
    Source code(zip)
    CPM.cmake(20.63 KB)
    get_cpm.cmake(847 bytes)
  • v0.28.1(Jan 25, 2021)

  • v0.28.0(Jan 20, 2021)

Owner
CPM.cmake
CPM.cmake
PMM - The C++ Package Manager Manager

PMM - The Package Manager Manager PMM is a module for CMake that manages... package managers. Wha- Why? People hate installing new software. Especiall

Edgar 12 Jun 28, 2022
Spack is a package manager, and package managers should be trivial to install.

?? Spack with batteries included (linux/x86_64) Spack is a package manager, and package managers should be trivial to install. This repo offers a sing

Harmen Stoppels 19 Nov 17, 2022
BakePKG is a package archive that can install itself without without a package manager.

BakePKG A bad way of packaging applications. Introduction BakePKG is a package archive that can install itself without without a package manager. The

bread 3 Sep 3, 2022
The decentralized package manager for C++ and friends 🏝️

Buckaroo The decentralized package manager for C++ and friends. Why Buckaroo? Package managers like Yarn and Cargo have shown how productive developer

LoopPerfect 899 Nov 16, 2022
Conan - The open-source C/C++ package manager

Conan Decentralized, open-source (MIT), C/C++ package manager.

Conan.io 6.4k Nov 21, 2022
C++ Library Manager for Windows, Linux, and MacOS

Vcpkg: Overview 中文总览 Español 한국어 Français Vcpkg helps you manage C and C++ libraries on Windows, Linux and MacOS. This tool and ecosystem are constant

Microsoft 17.2k Nov 24, 2022
C++ package retrieval

cget Cmake package retrieval. This can be used to download and install cmake packages. The advantages of using cget are: Non-intrusive: There is no ne

Paul Fultz II 417 Nov 15, 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.5k Nov 25, 2022
🚀 Kick-start your C++! A template for modern C++ projects using CMake, CI, code coverage, clang-format, reproducible dependency management and much more.

ModernCppStarter Setting up a new C++ project usually requires a significant amount of preparation and boilerplate code, even more so for modern C++ p

Lars Melchior 3k Nov 19, 2022
CMake driven cross-platform package manager for C/C++.

Hunter CMake driven cross-platform package manager for C/C++. Linux, Windows, macOS, iOS, Android, Raspberry Pi, etc. Documentation: https://hunter.re

null 484 Nov 19, 2022
Template for reliable, cross-platform C++ project setup using cmake.

The C++ CMake Project Template cmake-init is a sophisticated copy & paste template for modern C and C++ projects. The main goals include support of al

CG Internals 805 Nov 21, 2022
Non-intrusive CMake dependency management

cmodule Non-intrusive CMake dependency management. Normally CMake's find_package() looks for packages installed on host system (and compiled for host

scapix.com 14 Sep 29, 2022
⛵ The missing small and fast image decoding library for humans (not for machines).

Squirrel Abstract Image Library The missing fast and easy-to-use image decoding library for humans (not for machines). Target Audience • Features • Im

Dmitry Baryshev 203 Nov 14, 2022
Source code for the data dependency part of Jan Kossmann's PhD thesis "Unsupervised Database Optimization: Efficient Index Selection & Data Dependency-driven Query Optimization"

Unsupervised Database Optimization: Data Dependency-Driven Query Optimization Source code for the experiments presented in Chapter 8 of Jan Kossmann's

Jan Koßmann 4 Apr 24, 2022
A small, dependency-free node editor extension for dear imgui.

imnodes A small, dependency-free node editor extension for dear imgui. Features: Create nodes, links, and pins in an immediate-mode style Single heade

Johann Muszynski 1.3k Nov 16, 2022
PMM - The C++ Package Manager Manager

PMM - The Package Manager Manager PMM is a module for CMake that manages... package managers. Wha- Why? People hate installing new software. Especiall

Edgar 12 Jun 28, 2022
Spack is a package manager, and package managers should be trivial to install.

?? Spack with batteries included (linux/x86_64) Spack is a package manager, and package managers should be trivial to install. This repo offers a sing

Harmen Stoppels 19 Nov 17, 2022
BakePKG is a package archive that can install itself without without a package manager.

BakePKG A bad way of packaging applications. Introduction BakePKG is a package archive that can install itself without without a package manager. The

bread 3 Sep 3, 2022
A interpreter that runs the script which is programmed in the language of FF0 script (or you can call it as Warfarin)

ff0-script A interpreter that runs the script which is programmed in the language of FF0 script (or you can call it as Warfarin) You can do it, unders

null 24 Apr 27, 2022
CMake wrapper for Xrepo C and C++ package manager

xrepo-cmake CMake wrapper for Xrepo C and C++ package manager. Supporting the project Support this project by becoming a sponsor. Your logo will show

xmake-io 22 Nov 7, 2022