Hello,

Consider this:

 add_library(foo SHARED ...)
 add_library(bar SHARED ...)
 target_link_libraries(foo LINK_PRIVATE bar)

 install(TARGETS foo EXPORT FooTargets ...)
 install(TARGETS bar EXPORT BarTargets ...)

 install(EXPORT FooTargets ...)
 install(EXPORT BarTargets ...)

This is very common in the KDE Frameworks buildsystem currently. The targets 
are in a single monolithic buildsystem (currently), and are exported to 
different export sets.

Because foo contains

 IMPORTED_LINK_DEPENDENT_LIBRARIES "bar"

the 'bar' target is part of the missing target check code in 
cmExportFileGenerator::GenerateMissingTargetsCheckCode.

If bar was part of the same export set as foo, or if bar was an imported 
target, that would not be the case. However, then the correct -rpath-link 
entry may not be created for 'bar'. This has previously been considered a 
minor issue. Downstream can add a find_package for bar if it is in an 
unusual location.

How should this be resolved? Should the contents of 
IMPORTED_LINK_DEPENDENT_LIBRARIES be public package dependencies always? Or 
should they not be added to the public package dependencies as they are now 
in the above case? 

My preference is the latter. The patch is quite simple:

diff --git a/Source/cmExportFileGenerator.cxx 
b/Source/cmExportFileGenerator.cxx
index ef336ea..b67cc46 100644
--- a/Source/cmExportFileGenerator.cxx
+++ b/Source/cmExportFileGenerator.cxx
@@ -736,9 +736,11 @@ cmExportFileGenerator
                                 "IMPORTED_LINK_INTERFACE_LANGUAGES",
                                 iface->Languages, properties, 
missingTargets);
 
+    std::vector<std::string> dummy;
+
     this->SetImportLinkProperty(suffix, target,
                                 "IMPORTED_LINK_DEPENDENT_LIBRARIES",
-                                iface->SharedDeps, properties, 
missingTargets);
+                                iface->SharedDeps, properties, dummy);
     if(iface->Multiplicity > 0)
       {
       std::string prop = "IMPORTED_LINK_INTERFACE_MULTIPLICITY";


Thanks,

Steve.


--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Reply via email to