FetchContent and find_package

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

FetchContent and find_package

Saad Khattak
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.

- Saad

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: FetchContent and find_package

Craig Scott-3


On Tue, Apr 10, 2018 at 11:07 PM, Saad Khattak <[hidden email]> 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

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> wrote:

On Tue, Apr 10, 2018 at 11:07 PM, Saad Khattak <[hidden email]> 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

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: FetchContent and find_package

Craig Scott-3


On Wed, Apr 11, 2018 at 2:28 AM, Saad Khattak <[hidden email]> 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 <[hidden email]> wrote:

On Tue, Apr 10, 2018 at 11:07 PM, Saad Khattak <[hidden email]> 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

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake