One usage I would have had for this feature would have been to generate
a pre-linked library.
Basically, merging a static library and its dependencies together (check
ld -r) and output an object file for static linking (not a shared library).
This is required as merging static libraries may conflict on filenames
in the archive (they could be renamed though) or generate huge archives
(hey, here's 1000 copies of std::string and std::vector methods and
their debug symbols).
Instead, I recursed on all the dependencies to generate an extra build
step to merge everything. The file is small and can be cached.
We did that to save time for our iOS devs so they didn't have to rebuild
our big C++ library all the time. We targeted iOS 7, so shared libraries
were not available.
It's a bit more involved, but it would have been useful. Though, I
understand it can be tricky to get the on-disk path to a library with
all generators (we had 2 code paths, one for Xcode builds and another
one for Ninja).
/Florent
On 02/11/2016 12:56, Brad King wrote:
On 11/01/2016 04:30 PM, maikel van den Hurk wrote:
obtain actually all transitive linked libraries of a specific target.
[snip]
this information is only fully available during generation time.
What is an example use case for this? I don't think we can offer a
configure-time solution but perhaps there is a generate-time solution
to the use case.
-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
