Re: [cmake-developers] ExternalProject can't have interface library as a dependency
As far as I understand, IMPORT libraries are for different purposes. They should be used for files that are already exist. In other words, to import existing artifacts into the build system. I don't remember the exact details, but last time I tried to use IMPORT library for such purpose there was a cmake error saying that path (include dir or library) not exists, while it should. In my case openssl is also generated as a result of an external project, so I have to use INTERFACE library. On Tue, Apr 21, 2015 at 10:10 AM, Stephen Kelly steve...@gmail.com wrote: Andrey Pokrovskiy wrote: [Moved from cmake users mailing list] I have the following construction: ExternalProject_Add( websockets_ep DEPENDS ev openssl ...) But it so happened, that openssl is an INTERFACE library. It is an INTERFACE library, because I created it with add_library(openssl INTEFACE) and then populated corresponding INCLUDE and LINK properties. Sorry, I forgot to follow up on this on the user list. You probably want an IMPORT library instead of an INTERFACE one. That might already work for your dependency case with existing cmake releases. Thanks, Steve. -- 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-developers -- 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-developers
Re: [cmake-developers] ExternalProject can't have interface library as a dependency
Andrey Pokrovskiy wrote: In my case openssl is also generated as a result of an external project, so I have to use INTERFACE library. Ah, ok. I missed that part. Thanks, Steve. -- 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-developers
Re: [cmake-developers] ExternalProject can't have interface library as a dependency
On 04/21/2015 12:17 PM, Andrey Pokrovskiy wrote: I understand that, but I still don't understand why there is a need in file-level dependencies at all. When target level dependency will not be enough? Each step of an external project has a timestamp file to track whether it is up to date or not. The configure step of an external project gets a dependency on the done timestamp file of the EP's dependencies. This way when an external project is updated and re-built then its dependents get a chance to reconfigure and rebuild too. And what if I want to have a dependency on external project target in my code? Do I need to apply the same hack to also add a file-level dependency? Often the ordering dependency is enough. If you depend on library files created by the external project then you can add dependencies on them through other mechanisms like an IMPORTED library target. -Brad -- 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-developers
[cmake-developers] ExternalProject can't have interface library as a dependency
[Moved from cmake users mailing list]
I have the following construction:
ExternalProject_Add(
websockets_ep
DEPENDS ev openssl
...)
But it so happened, that openssl is an INTERFACE library. It is an
INTERFACE library, because I created it with add_library(openssl
INTEFACE) and then populated corresponding INCLUDE and LINK
properties. And I get an obscure error:
CMake Error at
/usr/share/cmake/share/cmake-3.2/Modules/ExternalProject.cmake:2031
(get_property):
INTERFACE_LIBRARY targets may only have whitelisted properties. The
property _EP_IS_EXTERNAL_PROJECT is not allowed.
Call Stack (most recent call first):
/usr/share/cmake/share/cmake-3.2/Modules/ExternalProject.cmake:2328
(_ep_add_configure_command)
src/libwebsockets/CMakeLists.txt:21 (ExternalProject_Add)
Apparently because there is a check inside get_property() that
whitelists what properties could be queried.
My first idea was that having a whitelist for get_property() is
probably not that good idea.
But then I realized that I don't understand why ExternalProject cares
about whether dependency is also an external project. What the
difference it makes? Does that means that it's not safe to use
external project target with add_dependencies()?
ExternalProject_Add() already have code that should cover all cases:
# Depend on other external projects (target-level).
get_property(deps TARGET ${name} PROPERTY _EP_DEPENDS)
foreach(arg IN LISTS deps)
add_dependencies(${name} ${arg})
endforeach()
Why there is a special case when dependency is also an external project?
--
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-developers
Re: [cmake-developers] ExternalProject can't have interface library as a dependency
To avoid this entirely, you can just use add_dependencies (
http://www.cmake.org/cmake/help/v3.2/command/add_dependencies.html )
instead of adding it as a DEPENDS to your ExternalProject_Add call.
The reason ExternalProject_Add queries to see if the other thing is an
ExternalProject or not is to set up file level dependencies between a
step of that project and the configure step of this project. If it is,
it sets it up... if not, it has the same effect as a direct
add_dependencies call.
(But I have no idea why there are even whitelisted properties to tell
you the truth. I've been reading along here waiting for somebody
to explain that one. ;-)
HTH,
David
On Tue, Apr 21, 2015 at 3:34 AM, Andrey Pokrovskiy
wonder.m...@gmail.com wrote:
[Moved from cmake users mailing list]
I have the following construction:
ExternalProject_Add(
websockets_ep
DEPENDS ev openssl
...)
But it so happened, that openssl is an INTERFACE library. It is an
INTERFACE library, because I created it with add_library(openssl
INTEFACE) and then populated corresponding INCLUDE and LINK
properties. And I get an obscure error:
CMake Error at
/usr/share/cmake/share/cmake-3.2/Modules/ExternalProject.cmake:2031
(get_property):
INTERFACE_LIBRARY targets may only have whitelisted properties. The
property _EP_IS_EXTERNAL_PROJECT is not allowed.
Call Stack (most recent call first):
/usr/share/cmake/share/cmake-3.2/Modules/ExternalProject.cmake:2328
(_ep_add_configure_command)
src/libwebsockets/CMakeLists.txt:21 (ExternalProject_Add)
Apparently because there is a check inside get_property() that
whitelists what properties could be queried.
My first idea was that having a whitelist for get_property() is
probably not that good idea.
But then I realized that I don't understand why ExternalProject cares
about whether dependency is also an external project. What the
difference it makes? Does that means that it's not safe to use
external project target with add_dependencies()?
ExternalProject_Add() already have code that should cover all cases:
# Depend on other external projects (target-level).
get_property(deps TARGET ${name} PROPERTY _EP_DEPENDS)
foreach(arg IN LISTS deps)
add_dependencies(${name} ${arg})
endforeach()
Why there is a special case when dependency is also an external project?
--
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-developers
--
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-developers
Re: [cmake-developers] ExternalProject can't have interface library as a dependency
On 04/21/2015 03:34 AM, Andrey Pokrovskiy wrote: CMake Error at /usr/share/cmake/share/cmake-3.2/Modules/ExternalProject.cmake:2031 (get_property): INTERFACE_LIBRARY targets may only have whitelisted properties. The property _EP_IS_EXTERNAL_PROJECT is not allowed. Call Stack (most recent call first): /usr/share/cmake/share/cmake-3.2/Modules/ExternalProject.cmake:2328 (_ep_add_configure_command) src/libwebsockets/CMakeLists.txt:21 (ExternalProject_Add) Fixed: ExternalProject: Allow dependencies on INTERFACE libraries http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4bce6c5d My first idea was that having a whitelist for get_property() is probably not that good idea. The idea is to restrict INTERFACE libraries as much as possible to intended use cases so we can expand later without breaking projects depending on undefined behavior. Why there is a special case when dependency is also an external project? When one external project depends on another then we add both the target-level ordering dependencies (add_dependencies) and add file-level dependencies on the stamp files so that things re-run when needed. -Brad -- 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-developers
Re: [cmake-developers] ExternalProject can't have interface library as a dependency
Andrey Pokrovskiy wrote: [Moved from cmake users mailing list] I have the following construction: ExternalProject_Add( websockets_ep DEPENDS ev openssl ...) But it so happened, that openssl is an INTERFACE library. It is an INTERFACE library, because I created it with add_library(openssl INTEFACE) and then populated corresponding INCLUDE and LINK properties. Sorry, I forgot to follow up on this on the user list. You probably want an IMPORT library instead of an INTERFACE one. That might already work for your dependency case with existing cmake releases. Thanks, Steve. -- 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-developers
Re: [cmake-developers] ExternalProject can't have interface library as a dependency
Thanks for fixing that, Brad! Why there is a special case when dependency is also an external project? When one external project depends on another then we add both the target-level ordering dependencies (add_dependencies) and add file-level dependencies on the stamp files so that things re-run when needed. I understand that, but I still don't understand why there is a need in file-level dependencies at all. When target level dependency will not be enough? And what if I want to have a dependency on external project target in my code? Do I need to apply the same hack to also add a file-level dependency? On Tue, Apr 21, 2015 at 8:38 AM, Brad King brad.k...@kitware.com wrote: On 04/21/2015 03:34 AM, Andrey Pokrovskiy wrote: CMake Error at /usr/share/cmake/share/cmake-3.2/Modules/ExternalProject.cmake:2031 (get_property): INTERFACE_LIBRARY targets may only have whitelisted properties. The property _EP_IS_EXTERNAL_PROJECT is not allowed. Call Stack (most recent call first): /usr/share/cmake/share/cmake-3.2/Modules/ExternalProject.cmake:2328 (_ep_add_configure_command) src/libwebsockets/CMakeLists.txt:21 (ExternalProject_Add) Fixed: ExternalProject: Allow dependencies on INTERFACE libraries http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4bce6c5d My first idea was that having a whitelist for get_property() is probably not that good idea. The idea is to restrict INTERFACE libraries as much as possible to intended use cases so we can expand later without breaking projects depending on undefined behavior. Why there is a special case when dependency is also an external project? When one external project depends on another then we add both the target-level ordering dependencies (add_dependencies) and add file-level dependencies on the stamp files so that things re-run when needed. -Brad -- 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-developers
