[CMake] FetchContent and find_package

[Craig Scott]

On Wed, Apr 11, 2018 at 2:28 AM, Saad Khattak <saadrustam at gmail.com> wrote:

> Thank you Craig.
>
> >> Imported targets are definitely more preferable though
>
> Can you please elaborate on this?
>

Variables are the old way of passing details about a target to a consuming
target. It was customary to provide one variable listing the library that
consuming projects would link to, then another variable would provide
header search paths, maybe yet another for compiler defines, and so on.
This is fragile and doesn't provide transitive dependencies (also sometimes
called usage requirements), so the consuming project may then have to work
out what other libraries it had to link to as well, what other header
search paths it might need and so on. Imported targets address all of those
problems. They act just like a regular target in the sense that they
support usage requirements, so anything that links to them also gets the
information about what other libraries to link against, what header search
paths to add, etc. CMake automatically uses those details to augment the
necessary command lines without you having to do anything. Basically you
just link against the imported target and that's job done from the
project's perspective. Much more robust, way easier to use.




> 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/20180411/71291fc1/attachment.html>