<div dir="ltr">Private doesn't work because the names in A need to be part of the public interface. </div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 22, 2016 at 11:51 AM, Nicholas Braden <span dir="ltr"><<a href="mailto:nicholas11braden@gmail.com" target="_blank">nicholas11braden@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Have you tried using the PRIVATE keyword when linking to A?<br>
<a href="https://cmake.org/cmake/help/latest/command/target_link_libraries.html#libraries-for-a-target-and-or-its-dependents" rel="noreferrer" target="_blank">https://cmake.org/cmake/help/latest/command/target_link_libraries.html#libraries-for-a-target-and-or-its-dependents</a><br>
<div><div class="h5"><br>
On Fri, Jan 22, 2016 at 9:14 AM, Jack Stalnaker <<a href="mailto:omnijack@gmail.com">omnijack@gmail.com</a>> wrote:<br>
> Is there any way to exclude a dependency from an export? If I build a static<br>
> library target "A" but do not wish to install it, and then link that target<br>
> to another target "B" using target_link_libraries(B A), and then attempt to<br>
> export B, I get the error message:<br>
><br>
> install (EXPORT "B" ...) includes target "B" which requires target "A" that<br>
> is not in the export set.<br>
><br>
> I can solve the problem by installing A, but there is no need to. It is a<br>
> temporary target that is statically linked. I just need to export for<br>
> creating a package config file, so there's no need for the package config to<br>
> ever need to worry about statically linked libraries.<br>
><br>
> Is there a workaround for this?<br>
><br>
> Long story short, I am trying to replicate convenience libraries from<br>
> autotools. I'm having a hell of time doing it. I can use lists of sources,<br>
> but that requires passing around global variables that include the sources<br>
> and others that include the required libraries. This is far messier and far<br>
> less convenient. I've tried object libraries, and while they eliminate the<br>
> global source variables and prevent rebuilding things, they fail when the<br>
> source is nested, and you want to build a "super library" from smaller<br>
> object libraries, which I believe is a fairly common working pattern.<br>
> Building a static library that is never installed works really well ...<br>
> until I go to create a package config file. Then this export fails.<br>
><br>
> Thanks,<br>
> --Jack<br>
><br>
</div></div>> --<br>
><br>
> Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
><br>
> Please keep messages on-topic and check the CMake FAQ at:<br>
> <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
><br>
> Kitware offers various services to support the CMake community. For more<br>
> information on each offering, please visit:<br>
><br>
> CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/support.html</a><br>
> CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/consulting.html</a><br>
> CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/training.html</a><br>
><br>
> Visit other Kitware open-source projects at<br>
> <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://public.kitware.com/mailman/listinfo/cmake" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/cmake</a><br>
</blockquote></div><br></div>