<div dir="ltr"><div>I've found several workarounds, though I'm not sure of the long term ramifications. </div><div><br></div><div>1. I can "install" library A to CMAKE_CURRENT_BINARY_DIR effectively doing nothing. Since A is never referenced, only consumed, this should be okay?</div><div><br></div><div>2. I can remove the export from both A's and B's install, and simply not include the target.cmake file in my package config prototype. I can just include my targets as variables the same way a FindXXX.cmake file does. Makes the syntax slightly uglier in that you cannot refer to B by target name. It also might break the expectations of a user who thinks a package should include target names. </div><div><br></div><div>I've started several discussions here on convenience libraries, and I think I'm starting to realize the Cmake team has a different definition than I do. To me, a convenience lib is not just an archived collection of sources. The convenience lib is already linked to any external libs and already was compiled with any special flags--in essence it's fully cooked. The nice thing about this is that it keeps all the details specific to that part of the code confined to that code's place on disc and that part of the code's CMakeLists.txt. Object libraries and source list variables require that other information to be passed around as well, leaking the convenience lib's requirements all over the code tree. You could argue that that means A should be a plain old library, then, but installing it serves no purpose. It will like never be referenced outside of the code tree, and it pollutes the system library folder. </div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 22, 2016 at 1:20 PM, Jack Stalnaker <span dir="ltr"><<a href="mailto:jack.stalnaker@gmail.com" target="_blank">jack.stalnaker@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Private doesn't work because the names in A need to be part of the public interface. </div><div class="HOEnZb"><div class="h5"><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><br>
On Fri, Jan 22, 2016 at 9:14 AM, Jack Stalnaker <<a href="mailto:omnijack@gmail.com" target="_blank">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>
</div></div></blockquote></div><br></div>