I'd need to look into it more to find how other projects accomplish this, but I'd guess that they incorporate the necessary find_package / pkg_check_modules calls in the CMake config to make the imported targets available. I think this would end up being more portable than using hard-coded paths or assuming everything can be found in system include and library directories.

@jwillikers I'd be all ears if you found a workable solution other (better) than mine in above mentioned commits.

1. The missing headers (i.e. their search directories) to build FLTK itself are added in my commits. This concerns only building the FLTK library itself.
2. The link libraries found by pkg-config are provided by absolute paths to the libs in the FLTK targets in FLTKConfig.cmake or in the related FLTK-Targets file. This seems to be useful (and intended by CMake) because you might otherwise find different shared libs on a system in the consumer's CMake environment.

Regarding "portability": if the Conan build includes "special" shared libs in the Conan build environment then the application linking to FLTK must IMHO be linked to these specific shared libraries (which is done with the current version). I can see problems if the libs linked to by the FLTK library are moved (installed) and then deleted because absolute paths are used by the linker. I have no idea how this could be solved. Also, deploying built user programs to other systems might be an issue. This is fragile anyway (although I see users doing this) and I don't know how to solve this too. Or maybe this isn't a problem at all, I don't know.

—
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/c2068142603@github.com>