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
Subsequent calls to project() from sub-directories is supported. For
calls to project from sub-directories it does everything but set
CMAKE_PROJECT_NAME.
On Wed, Jul 24, 2019 at 7:29 AM Jason Beach wrote:
>
> I've been reorganizing / updating our software cmake build. It currently uses
> a mixtu
