[cmake-developers] IMPORTED targets for some Find modules

Stephen Kelly steveire at gmail.com
Tue Jun 24 17:37:05 EDT 2014


Philipp Möller wrote:

> To simplify exporting targets I added IMPORTED targets to some of the
> Find modules.

Thanks for working on this. Just a few minor comments:

In the FindX11 documentation commit, one of the changes is to replace use of 
two spaces between sentences with one. That's counter to the prevailing 
style in CMake.

cmExportFileGenerator marks frameworks with a FRAMEWORK target property, and 
Qt 5 emulates that. It could be done with these files too (I notice in 
FindGLUT at least). I don't know if it has any effect on IMPORTED targets, 
but it may in the future even if it does not currently.

Is there any reason to make the boost components not depend on each other? 
Or is that just left for future development?

The Boost module documents that component imported targets have lower-case 
names, but that is not the case (haha). The names depend on the arguments to 
find_package currently:

 find_package(Boost REQUIRED Thread)

 if (TARGET Boost::Thread)
   message("YES")
 else()
   message("NO")
 endif()

It looks like a good idea to add Boost::boost to the 
INTERFACE_LINK_LIBRARIES of each component imported target, or to similarly 
populate the INTERFACE_INCLUDE_DIRECTORIES of each component imported 
target.

I would say something similar about the GLUT imported targets, but it seems 
that only GLUT::GLUT is documented, so presumably it is the only one 
intended for users to use. Is it verified that the other libraries are 
really interface dependencies and not runtime requirements? If they are 
really interface usage requirements, where are the headers of the other 
libraries located?

Multiple IMPORTED_LOCATION_<CONFIG> are populated on the boost targets, but 
the IMPORTED_CONFIGURATIONS target property is not populated.

Is there a need to populate the IMPORTED_IMPLIB_<CONFIG> target properties 
on Windows for any of the targets?

cmExportFileGenerator populates the IMPORTED_LINK_INTERFACE_LANGUAGES target 
property, and Qt 5 emulates that. The same could be set to CXX at least for 
the Boost targets.

One of the reasons Qt imported targets are called Qt4::Foo and Qt5::Foo is 
to avoid accidental combination of, say, Qt::Core and Qt::Gui from different 
major versions. They also encode a INTERFACE_QT_MAJOR_VERSION and add  
QT_MAJOR_VERSION to the COMPATIBLE_INTERFACE_STRING target property. 
Something similar could be added for these imported targets.

In the case of Boost, because they don't provide binary compatibility or 
promise source compatibility, it might make sense to encode the full 
version, not only the major version, in a similar way to ensure that only 
boost libraries from the same boost release are used together. In the 
future, post modularization, boost may attempt to release some modules on a 
separate release schedule and with disparate version numbers. They may still 
release 'boost foobar 1.3' with 'Boost 1.58' though, so '1.58' would still 
be the appropriate 'distribution version' to encode. 

[Aside: Some people want to release Qt modules with disparate version 
schemes too, which has already caused problems:

 http://thread.gmane.org/gmane.comp.lib.qt.devel/17144

One of the remaining unsolved problems is that Qt5 packages find their 
dependencies with the same version as themselves, so

 find_package(Qt5Gui)

which finds a version 5.3.1 Qt5Gui package will call

 find_package(Qt5Core 5.3.1)

This obviously would either require mappings to be maintained ('what version 
of Qt5 was Enginio 1.0.5/1.2.3 released with?'), or would need to be 
dropped. That would be unfortunate because only combinations in the same 
'distribution version' (which corresponds to the QtCore version) are tested 
together. 

But I digress...
]

In the case of boost, it would also make sense to add 
INTERFACE_MULTITHREADED to the targets and COMPATIBLE_INTERFACE_BOOL. I'm 
assuming that a multithreaded Boost::system can't be used with a non-
multithreaded Boost::filesystem for example. Currently I have the debian 
package libboost-thread1.54-dev installed on my system but not the package 
libboost-system1.54-dev, so FindBoost will find the thread component but not 
the system component (in that prefix at least). Depending on the 
build/package of boost it might be possible to conflict on things like that.

Others to consider for this compatibility requirement are the 
Boost_COMPILER, Boost_NAMESPACE, Boost_THREADAPI etc.

Thanks,

Steve.





More information about the cmake-developers mailing list