[CMake] FetchContent and find_package

Craig Scott craig.scott at crascit.com
Tue Apr 10 10:23:54 EDT 2018


On Tue, Apr 10, 2018 at 11:07 PM, Saad Khattak <saadrustam at gmail.com> wrote:

> Hi,
>
> My project is setup in such a way that I perform a FetchContent 'only if'
> my find_package fails.
>
> This works very well until I start building different configurations.
> Let's say I generate and build Debug for my project. My project tries to
> find_package(LibA QUIET) and cannot find it. So, it performs a
> FetchContent(...) step, builds the dependency and my library and installs
> everything. This works flawlessly.
>
> Now I start building a Release version with different build and install
> folders. Unfortunately, find_package(LibA QUIET) finds the Debug libraries
> and does not perform a FetchContent(...) step and in turn doesn't build the
> Release version of the dependent library. Consequently, the linking step
> fails.
>
> Is there an easy way around this issue?
>
> I say 'easy' because I could write some CMake scripts to search for the
> libraries after a successful find_package(...) and if it only finds
> libraries for Debug when it really wants Release, it performs a
> FetchContent(...). However, this could be quite fragile.
>
> It would be nice if CMake has a way of knowing if an installed library,
> found through find_package(...) is Debug, Release, RelWithDebInfo etc.
>

If the package found by find_package() is picking up a config file
generated by CMake, then you can check the IMPORTED_CONFIGURATIONS property
of its imported target(s). This will give you a list of configurations the
package provides. Ideally, a single package should cover all relevant build
types, not one package per build type. This is up to the project itself
though and how it builds/installs its package. If the found package only
provides variables instead of imported targets, then you'll have to work
harder and go through whatever variables it provides to see if you can work
out what the package can give you. Imported targets are definitely more
preferable though.

-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180411/7195fbed/attachment.html>


More information about the CMake mailing list