This works! Thank you!!

Great, thanks for the feedback.

CMake's pkg_check_modules seems to predate its support for imported targets...

Yup, CMake docs say that IMPORTED_TARGET has been added in CMake 3.6. But I don't think that this is relevant for our problem.

Let's recap what happened:

1. Your PR added the IMPORTED_TARGET argument in an attempt to use the imported target directly in target_link_libraries().
2. Although this worked for your Conan build of the FLTK library itself it broke a simple "Hello World" consumer project.
3. My solution to (2.) was to extract the link libraries and include directories from the imported PkgConfig:: target and to add them as target_link_libraries() and target_include_directories() to the target fltk (fltk::fltk) etc..

In retrospect we could have used the respective PkgConfig variables directly in the first place but I'm not going to turn this back.

CMake seems to provide find_dependency for this purpose, as it's meant to be used in CMake package files, but it's meant to easily work for find_package calls and not pkg_check_modules calls.

Note: our goal is to create one target (fltk::fltk) that provides all its dependencies for consumer projects by using the FLTKConfig.cmake file. That's how I understand the "modern CMake" approach with CMake config files, and this is what happens now: the target fltk::fltk contains all informations needed by the consumer project. System introspection ("finding" dependencies) by the consumer project is not necessary and IMHO not desirable. We do already know all dependencies and if we tried to "find" them in the FLTKConfig.cmake file (again) we might even find the wrong versions of some libraries and make the link fail or produce runtime errors.

Therefore I believe that our current solution is good as it is. Thanks for all your help.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <fltk/fltk/pull/954/c2069290886@github.com>