cpm-cmake / CPM.cmake

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

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

CPMFindPackage() does not appear to allow specifying of COMPONENTS

saxbophone opened this issue · comments

Opening a new issue with my original comment on closed issue #250...

For real though, how does one pass through to the COMPONENTS parameter of CMake's find_package() when using CPMFindPackage() ?

I have SFML installed locally, but the following:

CPMFindPackage(
    NAME SFML
    GIT_REPOSITORY https://github.com/SFML/SFML.git
    GIT_TAG        2.5.1
    EXCLUDE_FROM_ALL YES
    OPTIONS "BUILD_SHARED_LIBS FALSE" # force SFML to build as static lib for ease of distribution
)

Fails with:

CMake Error at /usr/lib/x86_64-linux-gnu/cmake/SFML/SFMLConfig.cmake:63 (message):
  find_package(SFML) called with no component
Call Stack (most recent call first):
  cmake/Modules/CPM.cmake:147 (find_package)
  cmake/Modules/CPM.cmake:198 (cpm_find_package)
  CMakeLists.txt:111 (CPMFindPackage)

Alas, changing it to:

CPMFindPackage(
    NAME SFML
    GIT_REPOSITORY https://github.com/SFML/SFML.git
    GIT_TAG        2.5.1
    EXCLUDE_FROM_ALL YES
    OPTIONS "BUILD_SHARED_LIBS FALSE" # force SFML to build as static lib for ease of distribution
    COMPONENTS graphics
)

makes no difference :(

Originally posted by @saxbophone in #250 (comment)

You should be able to provide arguments for find_package using the FIND_PACKAGE_ARGUMENTS parameter.

Edit: Actually there does not seem to be any test or example of this feature in the project. We should definitely add a test case for this.

You should be able to provide arguments for find_package using the FIND_PACKAGE_ARGUMENTS parameter.

Thanks, I must've missed the docs for that because I was searching specifically for the COMPONENTS parameter. It looks like I'm not the only one as I've seen other users share code samples attempting to use COMPONENTS with CPMFindPackage()/CPMAddPackage(), which appears to actually be incorrect as such usage does not pass it on to find_package(), to the best of my knowledge.

I will try your suggestion later to check it works for the sample usage I have.

I just wanted to check with you, so is something like this the correct usage?

CPMFindPackage(
    NAME Boost
    VERSION 1.73.0
    URL https://dl.bintray.com/boostorg/release/1.73.0/source/boost_1_73_0.tar.gz
    URL_HASH SHA256=9995e192e68528793755692917f9eb6422f3052a53c5e13ba278a228af6c7acf
    FIND_PACKAGE_ARGUMENTS "COMPONENTS program_options"
)

(from #210)

Edit: Actually there does not seem to be any test or example of this feature in the project. We should definitely add a test case for this.

I think this is a super good idea. I would also suggest, maybe documenting it as "how to specify components, as well as other find_package()" arguments as (I could be wrong) but this seems like a particularly pertinent argument for find_package() —SFML now won't work without it, to take my original example!

I just wanted to check with you, so is something like this the correct usage?

Looks good to me.

Note that I don't recommend using CPMFindPacakge though, as it has a ton of edge-cases like this and creates unpredictability in a build (just like the original find_package). If you want your project to behave as predictable as possible I'd definitely recommend to use CPMAddPackage where possible.

Note that I don't recommend using CPMFindPacakge though, as it has a ton of edge-cases like this and creates unpredictability in a build (just like the original find_package).

So I'm aware of unpredictability due to it either using a previously installed copy of said package or building it from source in-tree, depending on whether it's installed or not —I'm generally ok with opting into that level of unpredictability because for me, the convenience of letting the build system work that out for me and having builds that will work regardless of whether it's already installed or not trumps the unpredictability.

However, I'm not aware of the original find_package() introducing unpredictability —I have some reading up to do here, clearly. I guess I should re-read your docs to discover why CPMAddPackage() is more reproducible than both.

Thanks for the recommendation, I think it's always good to know what you're getting into and have all the information available when making a decision on how to go, and I think the CPMFindPackage() route is useful despite its caveats.

I am pleased to report back that using FIND_PACKAGE_ARGUMENTS "COMPONENTS ..." as you suggest does indeed fix my issue. Cheers!

Maybe this usage could be documented more explicitly as part of the work writing tests for it that you mentioned?

I think some sample of how to replace a call to find_package() with additional arguments such as COMPONENTS and/or others, along with the equivalent CPMFindPackage() call could be useful...

Happy it solved your issue! I agree that adding better documentation would a good idea.