Hi Craig: It appears you pretty much made the definitive statement about target_link_libraries (TLL) <INTERFACE|PUBLIC|PRIVATE> options at <https://cmake.org/pipermail/cmake/2016-May/063400.html>. However, I have some further questions about this key section of your statement:
"[...] when A links in B as PRIVATE, the include directories of B never propagate to something linking to A, but if A is a static library, then the *linking* of B behaves as though the relationship was PUBLIC. This PRIVATE-becomes-PUBLIC behaviour for static libraries only applies to the *linking*, not to the other dependencies (compiler options/flags and include search paths). The upshot of all this is that if you select PRIVATE, PUBLIC or INTERFACE based on the explanations in the dot points above, then CMake will ensure dependencies propagate through to where they are required, regardless of whether libraries are static or shared. This does, of course, rely on you the developer not missing any dependencies or specifying the wrong PRIVATE/PUBLIC/INTERFACE relationship." The issues I am concerned with are the following: * The target_include_directories, target_compile_definitions, and target_compile_options (TID, TCD, and TCO) commands all have <INTERFACE|PUBLIC|PRIVATE> options. I am pretty sure those options must take precedence over the TLL <INTERFACE|PUBLIC|PRIVATE> options, but can you confirm that? * It appears to me that if a CMake-based build system is configured properly there is very little need for the PUBLIC option for TLL because PRIVATE works well for shared libraries and the PRIVATE-becomes-PUBLIC behaviour for static libraries you mentioned above. Can you confirm this statement is generally true both for Unix and Windows? I am concerned with the above issues because the PLplot build system currently does the following: * For shared libraries uses the PRIVATE TLL option for the Unix case and PUBLIC TLL option for the Windows case. * For static libraries always uses the PUBLIC TLL option. These decisions were based on my own understanding of transitive linking needs for static Unix libraries and shared and static Windows libraries many years ago, but now it appears that understanding is out of date or else was wrong in the first place. For example, in the static Linux case there is a nasty leakage of compile and link flags between static libraries that I have just tripped over when dealing with the D ldc2 compiler which cannot understand those flags which are generated for the gcc compiler for a C library which our D library depends on. So to stop that leakage, and in light of what you said three years ago, it appears to be a no-brainer to use PRIVATE TLL for the PLplot static libraries at least in the Unix case. So assuming that for the PLplot build system I follow up and prove that PRIVATE TLL works for both the shared and static library cases on Unix, would you also recommend PLplot move to PRIVATE TLL for both the shared and static library cases on Windows? Thanks in advance for your further comments on these matters. Alan __________________________ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ -- 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: https://cmake.org/mailman/listinfo/cmake