On 29 June 2016 at 05:08, Raymond Wan <rwan.w...@gmail.com> wrote: > I agree that what we're observing is a problem, but I don't think it is that big.
I must admit I am mixing a bit of my own situation here and trying to think about the most general case. It's just there is a missing bit in the dependency search system and how far will it bleed into a project depends on the situation. In my case it breaks on static libraries. Neither installing in same stage directory nor ExternalProject go around the fact that such targets just does not provide enough to link against them. In case of dynamic libraries, it breaks if components are not located in (or installed to during build) the same path. Library B may find its dependency with some help (e. g. LIB_A_PATH during configure) and list libA.so in the dynamic section. But the next steps will still need to know libA.so location to link. On 29 June 2016 at 05:08, Raymond Wan <rwan.w...@gmail.com> wrote: > ExternalProject which will grab a repository and build it. Still, what about the fact that ExternalProject provides dependency information on the main project build step, after the configuration? I've found it quite disappointing and severely limiting ExternalProject usefulness. Especially with CMake-based projects where you cannot use usual find_package to search for that external project because its configuration file would not be installed until much later.
-- 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
