Unfortunately, your approach won't work %(
- first of all to write a `*-config.cmake` file the user gonna use
`configure_package_config_file` (which is end up w/ `configure_file`).
there is no place to use `file(GENERATE...)` since its result appears too
late...
- Ok, I can imagine that in the mid
In general you match every find_package call in your project with one
in your generate config file. If you have complicated conditional
dependencies you might be able to use file(GENERATE to determine which
ones will be used.
On Thu, Jul 25, 2019 at 11:02 AM Alex Turbov wrote:
>
> > It is than u
> It is than up to each project to generate an Config module that does
the required find_package calls to re-locate ZLIB.
Problems begin when mentioned dependencies are wrapped into generator
expressions (e.g. $ or smth even more
complicated) -- how do I know what `find_packages` to include to my
target_link_libraries() when given an explicit path+filename as PUBLIC
( not PRIVATE ) will be part of the transitive dependencies. An
explicit path+filename is not a target to CMake, nor will CMake
compute that it maps to an existing target ( be it imported or a
'normal' target ).
> This makes me
As a followup to my previous email dated 7/15/19, I learned from a
co-worker this week that if Project A's target_link_libraries() links
against an explicit path+filename of an external library, a subsequent
install(TARGETS ...) command will actually include that dependency in the
exported target f
I'd like to discuss some shortcomings of CMake with regards to sharing
targets among projects. Other people have brought this up on this mailing
list in the past, but there has never been any useful feedback on it.
I'm going to refer to two projects:
- "Project A" produces some libraries
- "Projec
