[CMake] Where is QT_USE_IMPORTED_TARGETS not safe to use?

[Clinton Stimpson]

On Monday, June 20, 2011 04:09:00 pm Stephen Kelly wrote:
> Hi,
> 
> The FindQt4 module has this to say about QT_USE_IMPORTED_TARGETS:
> > If QT_USE_IMPORTED_TARGETS is enabled, the QT_QTFOO_LIBRARY variables are
> > set to point at these imported targets. This works better in general, and
> > is also in almost all cases fully backward compatible. The only issue is
> > when a project A which had this enabled then exports its libraries via
> > export or EXPORT_LIBRARY_DEPENDENCIES(). In this case the libraries from
> > project A will depend on the imported Qt targets, and the names of these
> > imported targets will be stored in the dependency files on disk.
> 
> The part that is not clear to me is this:
> > This
> > means when a project B then uses project A, these imported targets must
> > be created again, otherwise e.g. "Qt4__QtCore" will be interpreted as
> > name of a library file on disk, and not as a target, and linking will
> > fail.
> 
> What does it mean to say that the imported targets must be created again?
> Is it a source incompatibility? Does it mean that my downstreams have to
> use QT_USE_IMPORTED_TARGETS if I do?

That applies if you use the install(EXPORT) command to create imported targets 
of the Grantlee libraries.  That cmake generated file could then be included in 
your GrantleeConfig.cmake.  If you used QT_USE_IMPORTED_TARGETS, it would 
contain the imported target names in that cmake generated export file, 
otherwise it would contain full paths to Qt libraries on your system.

The GrantleeConfig.cmake could set QT_USE_IMPORTED_TARGETS and a 
find_package(Qt4) to recreated those imported targets.

> 
> The KDE techbase page has additional caveats such as checking for file
> endings of the libraries etc I guess. I don't do such things in Grantlee,
> but if the use of QT_USE_IMPORTED_TARGETS affects downstreams too (as
> above) it might be relevant.
> 
> http://techbase.kde.org/Development/CMake_KDE_4_4#FindQt4.cmake:_Imported_T
> argets_for_the_libraries
> 
> Would using the variable have any real benefit? 

If you used install(EXPORT), the benefit would be that cmake would take care of 
the dependencies for you, and it would not have the full paths to libraries 
(if that matters to your users).

> I have the following in my
> CMakeLists which I suspect may be removable if I use the variable:
> 
> 
>     # http://mail.kde.org/pipermail/kde-windows/2007-December/001692.html
>     #
> http://lists.trolltech.com/pipermail/qt-interest/2009-July/009829.html #
> qt is always compiled with QT_NO_DEBUG under mingw,
>     # so we need to compile stuff linked against it
>     # the same or otherwise QPluginLoader rejects plugins
>     add_definitions(-DQT_NO_DEBUG)

That is unrelated to imported targets.
There is currently no mechanism in CMake to have the FindQt4.cmake module 
handle QT_DEBUG/QT_NO_DEBUG preprocessor defines automatically.

One does not have this problem if the QT_USE_FILE is used.  Otherwise you may 
do what it does for your project to add the configuration dependent Qt 
preprocessor defines.  

SET_PROPERTY(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS_DEBUG QT_DEBUG)
SET_PROPERTY(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS_RELEASE 
QT_NO_DEBUG)
SET_PROPERTY(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS_RELWITHDEBINFO 
QT_NO_DEBUG)
SET_PROPERTY(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS_MINSIZEREL 
QT_NO_DEBUG)

-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com