<div dir="ltr">Thanks for the input. I will try to upload an example soon and upload an issue.<div><br></div><div>In the meantime, I think I'll go the route of providing a library of helper functions like `add_my_flag_target_definitions(other_library PRIVATE)` that any targets can call. It ends up being about the same amount of CMake code and doesn't run into the installation issues. If a client wants to bundle more of them together, they can simply create their own `add_my_superset_of_target_definitions(my_lib PRIVATE)` or something similar that calls all the other functions as needed.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 3, 2019 at 5:30 PM Craig Scott <<a href="mailto:craig.scott@crascit.com">craig.scott@crascit.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 4, 2019 at 2:27 AM Dustyn Blasig <<a href="mailto:dustyn@blasig.us" target="_blank">dustyn@blasig.us</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi All,<br><div><br></div><div>I have been cleaning up our legacy CMake to use newer features (available in 3.12+) including trying to use target_...() functions nearly exclusively. As part of this, I was toying with cleaning up our use cases for adding compiler flags and similar definitions using real targets and target_link_libraries.</div><div><br></div><div>For instance, as a simple example, let's say I wanted to add/provide a definition MY_FLAG, I could do something like...</div><div><br></div><div>```</div><div>add_library(my_flag INTERFACE)<br></div><div>target_compile_definitions(my_flag INTERFACE MY_FLAG=1)</div><div><br></div><div>add_library(other_library SHARED ...)</div><div>target_link_libraries(other_library ... <b>PRIVATE </b>my_flag)</div><div><br></div><div>export/install rules</div><div>```</div><div><br></div><div>I want this library to be private to my component, and it's only used under the PRIVATE banner. However, the issue I'm running into is with the install/export rules. I get an error similar to ...</div><div><br></div><div>```</div><div><div>CMake Error: install(EXPORT "MY_PROJECT" ...) includes target "other_library" which requires target "my_flag" that is not in the export set. </div><div>```</div><div><br></div><div>If my_flag is defined in my component, I can add it to the export set perhaps to workaround the issue, but in many cases, it would be coming from a helper script in another sub-project I'm fetching using FetchContent and don't want to expose the functionality via my export scripts.</div></div><div><br></div><div>(1) Is it recommended to use interface libraries to clean up compile defintions, etc.</div></div></div></blockquote><div><br></div><div><div>Personally, I don't typically use interface libraries to do this, I prefer to list the requirements directly on the targets that they apply to. Some people/projects may choose to collect a commonly used set of requirements into an interface library, but one drawback with that is it creates the temptation to lump a bunch of things together in that interface library "for convenience", but end up with some targets having requirements applied to them that aren't actually requirements for those targets at all. Used appropriately, the technique can be helpful, but don't over-use it. ;)</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>(2) Should it be possible to link privately such libraries and not have the export functionality complain?</div></div></div></blockquote><div><br></div><div>From a usage requirement point of view, the interface library shouldn't need to be exported/installed because it is private. However, from a linking point of view, a shared library still needs all other libraries it links against for the linker to succeed at link time. Interface libraries don't appear on the linker command line, so they shouldn't need to be installed for linking to succeed, but I'm wondering if CMake's internal logic isn't properly handling this. Can you<a href="https://gitlab.kitware.com/cmake/cmake/issues" target="_blank"> open an issue in CMake's gitlab</a> and attach a complete, minimal example which reproduces the error (seems you're almost there with the extracted commands above)?</div><div> </div></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Craig Scott<br><div>Melbourne, Australia</div><div><a href="https://crascit.com" target="_blank">https://crascit.com</a><br></div><div><br></div><div>Get the hand-book for every CMake user: <a href="https://crascit.com/professional-cmake/" target="_blank">Professional CMake: A Practical Guide</a><br></div><div>Consulting services (CMake, C++, build/release processes): <a href="https://crascit.com/services" target="_blank">https://crascit.com/services</a></div></div></div></div></div></div></div></div></div></div></div></div></div>
</blockquote></div>