--===============1013000987== Content-Type: multipart/alternative; boundary="0000000000001c3883058e836359" --0000000000001c3883058e836359 Content-Type: text/plain; charset="UTF-8" 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 middle of `*-config.cmake` one can do `include(genex-expanded-blah-blah.cmake)` which is the result of `file(GENERATE...)` from the CMake run. But, the next problem is to match imported targets (obviously generated as a list variable) to the package names, versions, and components suitable for `find_package`... - The next problem: some finders could be tuned via variables (e.g. `OPENSSL_USE_STATIC_LIBS`, `Boost_USE_MULTITHREADED`, &etc) or even worse -- finder was given a path hint to load particular build of the third-party dependency (e.g. `XXX_ROOT_DIR`)... So, I'd be happy if CMake could take care of imported targets (loaded via `find_package`) for me and allows me to easily generate an export targets file with required `find_packages` *really used* by my target... On Thu, Jul 25, 2019 at 6:22 PM Robert Maynard wrote: > 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 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 > `*-config.cmake`?? > > > > On Thu, Jul 25, 2019 at 5:49 PM Robert Maynard < > robert.maynard@kitware.com> wrote: > >> > >> 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 think that install(TARGETS ...) not supporting imported > targets is likely an oversight by the CMake developers > >> > >> When exporting targets CMake exports what import targets something it > >> depends on. So if you have target_link_libraries(my_target PUBLIC > >> ZLIB::ZLIB) CMake when exporting my_target will export it depends on > >> ZLIB::ZLIB. It does this so that export information is machine > >> relocatable. > >> It is than up to each project to generate an Config module that does > >> the required find_package calls to re-locate ZLIB. > >> > >> On Wed, Jul 24, 2019 at 6:36 PM Benjamin Shadwick < > benshadwick@gmail.com> wrote: > >> > > >> > 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 for Library A1, such that it will be picked up as a > transitive dependency when later linking Library A1 into a binary in > Project B. > >> > > >> > This makes me think that install(TARGETS ...) not supporting imported > targets is likely an oversight by the CMake developers. This ought to be > fixed, because it effectively discourages people from following the "modern > CMake" approach of using targets wherever possible. > >> > -- > >> > > >> > 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 > >> -- > >> > >> 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 > --0000000000001c3883058e836359 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Unfortunately, your approach won't work %(
<= div>
- first of all to write a `*-config.cmake` file the user= gonna use `configure_package_config_file` (which is end up w/ `configure_f= ile`). there is no place to use `file(GENERATE...)` since its result appear= s too late...
- Ok, I can imagine that in the middle of `*-co= nfig.cmake` one can do `include(genex-expanded-blah-blah.cmake)` which is t= he result of `file(GENERATE...)` from the CMake run. But, the next problem = is to match imported targets (obviously generated as a list variable) to th= e package names, versions, and components suitable for `find_package`...
- The next problem: some finders could be tuned via variables (e.g.= `OPENSSL_USE_STATIC_LIBS`, `Boost_USE_MULTITHREADED`, &etc) or even wo= rse -- finder was given a path hint to load particular build of the third-p= arty dependency (e.g. `XXX_ROOT_DIR`)...

So, I'= ;d be happy if CMake could take care of imported targets (loaded via `find_= package`) for me and allows me to easily generate an export targets file wi= th required `find_packages` *really used* by my target...



On Thu, Jul 25, 2019 at 6:22 PM Robert Maynard <robert.maynard@kitware.com> = wrote:
In genera= l 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 <i.zaufi@gmail.com> wrote:
>
> > It is than up to each project to generate an Config module that d= oes
> the required find_package calls to re-locate ZLIB.
>
> Problems begin when mentioned dependencies are wrapped into generator = expressions (e.g. $<TARGET_NAME_IF_EXISTS:ZLIB::ZLIB> or smth even mo= re complicated) -- how do I know what `find_packages` to include to my `*-c= onfig.cmake`??
>
> On Thu, Jul 25, 2019 at 5:49 PM Robert Maynard <robert.maynard@kitware.com= > wrote:
>>
>> target_link_libraries() when given an explicit path+filename as PU= BLIC
>> ( 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 think that install(TARGETS ...) not supporting = imported targets is likely an oversight by the CMake developers
>>
>> When exporting targets CMake exports what import targets something= it
>> depends on. So if you have target_link_libraries(my_target PUBLIC<= br> >> ZLIB::ZLIB) CMake when exporting my_target will export it depends = on
>> ZLIB::ZLIB. It does this so that export information is machine
>> relocatable.
>> It is than up to each project to generate an Config module that do= es
>> the required find_package calls to re-locate ZLIB.
>>
>> On Wed, Jul 24, 2019 at 6:36 PM Benjamin Shadwick <benshadwick@gmail.com>= ; wrote:
>> >
>> > As a followup to my previous email dated 7/15/19, I learned f= rom a co-worker this week that if Project A's target_link_libraries() l= inks against an explicit path+filename of an external library, a subsequent= install(TARGETS ...) command will actually include that dependency in the = exported target for Library A1, such that it will be picked up as a transit= ive dependency when later linking Library A1 into a binary in Project B. >> >
>> > This makes me think that install(TARGETS ...) not supporting = imported targets is likely an oversight by the CMake developers. This ought= to be fixed, because it effectively discourages people from following the = "modern CMake" approach of using targets wherever possible.
>> > --
>> >
>> > 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 communit= y. For more information on each offering, please visit:
>> >
>> > CMake Support: http://cmake.org/cmake/help/sup= port.html
>> > CMake Consulting: http://cmake.org/cmake/he= lp/consulting.html
>> > CMake Training Courses: http://cmake.org/cmak= e/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 >> --
>>
>> 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. Fo= r more information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.= html
>> CMake Consulting: http://cmake.org/cmake/help/co= nsulting.html
>> CMake Training Courses: http://cmake.org/cmake/hel= p/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
--0000000000001c3883058e836359-- --===============1013000987== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- 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 --===============1013000987==--