configuration packages, IMPORTED targets, and global scope

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

configuration packages, IMPORTED targets, and global scope

Robert Dailey-2
So it took me a while to figure out why find_package() calls I was
making (with CONFIG) option were not accessible outside of the
directory in which it was invoked. I realized that all targets seem to
be global by default except IMPORTED targets (according to
add_library() docs). I find this counterintuitive, since I expect
imported targets to behave the same as normal ones WRT scope.

Is there a reason that imported targets need to be explicitly made GLOBAL?

Barring that, I'd like to find some way to make find_package() convert
those imported targets to global. I don't see a target property I can
set or a command I can call to make an existing imported target a
global one. Any thoughts on workarounds? If there are none, are there
some changes we could make to CMake to support this behavior?

My use case is that I have a subdirectory I step into, which builds
various third party libraries and then follows up with a
find_package() call. I do this in a isolated but central place because
I have to set up various variables like CMAKE_PREFIX_PATH and many
others to isolate searches to a controlled location. Beyond this, if a
target needs one of these third party libs, the expectation is that
they only have to do target_link_libraries() with the import target
names to use those libs. However, because they are out of scope, they
can't use them.
--

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:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: configuration packages, IMPORTED targets, and global scope

Deniz Bahadir-2
Am 06.09.2017 um 20:24 schrieb Robert Dailey:

> So it took me a while to figure out why find_package() calls I was
> making (with CONFIG) option were not accessible outside of the
> directory in which it was invoked. I realized that all targets seem to
> be global by default except IMPORTED targets (according to
> add_library() docs). I find this counterintuitive, since I expect
> imported targets to behave the same as normal ones WRT scope.
>
> Is there a reason that imported targets need to be explicitly made GLOBAL?
>
> Barring that, I'd like to find some way to make find_package() convert
> those imported targets to global. I don't see a target property I can
> set or a command I can call to make an existing imported target a
> global one. Any thoughts on workarounds? If there are none, are there
> some changes we could make to CMake to support this behavior?

Just a two days ago I created an issue for this:
https://gitlab.kitware.com/cmake/cmake/issues/17256

It would probably help if you participate in that discussion.

> My use case is that I have a subdirectory I step into, which builds
> various third party libraries and then follows up with a
> find_package() call. I do this in a isolated but central place because
> I have to set up various variables like CMAKE_PREFIX_PATH and many
> others to isolate searches to a controlled location. Beyond this, if a
> target needs one of these third party libs, the expectation is that
> they only have to do target_link_libraries() with the import target
> names to use those libs. However, because they are out of scope, they
> can't use them.
>

HTH,
Deniz
--

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:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: configuration packages, IMPORTED targets, and global scope

Robert Dailey-2
Thanks, I am watching that discussion and will try to contribute where I can.

On Thu, Sep 7, 2017 at 4:02 AM, Deniz Bahadir <[hidden email]> wrote:

> Am 06.09.2017 um 20:24 schrieb Robert Dailey:
>>
>> So it took me a while to figure out why find_package() calls I was
>> making (with CONFIG) option were not accessible outside of the
>> directory in which it was invoked. I realized that all targets seem to
>> be global by default except IMPORTED targets (according to
>> add_library() docs). I find this counterintuitive, since I expect
>> imported targets to behave the same as normal ones WRT scope.
>>
>> Is there a reason that imported targets need to be explicitly made GLOBAL?
>>
>> Barring that, I'd like to find some way to make find_package() convert
>> those imported targets to global. I don't see a target property I can
>> set or a command I can call to make an existing imported target a
>> global one. Any thoughts on workarounds? If there are none, are there
>> some changes we could make to CMake to support this behavior?
>
>
> Just a two days ago I created an issue for this:
> https://gitlab.kitware.com/cmake/cmake/issues/17256
>
> It would probably help if you participate in that discussion.
>
>> My use case is that I have a subdirectory I step into, which builds
>> various third party libraries and then follows up with a
>> find_package() call. I do this in a isolated but central place because
>> I have to set up various variables like CMAKE_PREFIX_PATH and many
>> others to isolate searches to a controlled location. Beyond this, if a
>> target needs one of these third party libs, the expectation is that
>> they only have to do target_link_libraries() with the import target
>> names to use those libs. However, because they are out of scope, they
>> can't use them.
>>
>
> HTH,
> Deniz
> --
>
> 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:
> http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake