[cmake-developers] Private link depends can be public package depends
Stephen Kelly
steveire at gmail.com
Tue Sep 24 05:40:36 EDT 2013
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.
More information about the cmake-developers
mailing list