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.
--
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:
http://public.kitware.com/mailman/listinfo/cmake-developers
