[CMake] FetchContent and find_package

[Saad Khattak]

Thank you Craig.

>> Imported targets are definitely more preferable though

Can you please elaborate on this?

On Tue, Apr 10, 2018 at 10:23 AM Craig Scott <craig.scott at crascit.com>
wrote:

>
> 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/20180410/859662d0/attachment.html>