[CMake] Where is QT_USE_IMPORTED_TARGETS not safe to use?

[Clinton Stimpson]

On Tuesday, June 21, 2011 06:59:25 am Stephen Kelly wrote:
> Hi,
> 
> Thanks for the response. I've got a few followups.
> 
> Clinton Stimpson wrote:
> >> 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.
> 
> Yes, I am currently using install(EXPORT) already. The GrantleeTargets file
> is included in the GrantleeConfig file.
> 
> > 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.
> 
> Yes, with the option enabled the GrantleeTargets-debug contains
> 
> IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG "Qt4::QtCore"
> 
> and without it contains
> 
> IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG "/usr/lib/libQtCore.so"
> 
> However, somehow I don't think you understood what I was really asking, so
> I'll try again. What I don't understand is the comment about "imported
> targets must be created again". Initially I thought the comment was saying
> that a downstream from Grantlee would have to do something 'again' after
> Grantlee did it 'first', and I was wondering what the 'something' is. Now I
> think maybe the comment may only be about generating the GrantleeTargets-
> debug file again (at build time) to use the target instead of the path, and
> linking will fail until that is done.
> 
> Is that correct?

It means the target must be created again with something like
add_library(Qt4::QtCore UNKNOWN IMPORTED)

If GrantleeConfig.cmake were to do this:
SET(QT_USE_IMPORTED_TARGETS 1)
find_package(Qt4 REQUIRED)

then the imported targets would satisfy the Qt4::QtCore reference and others 
from your GrantleeTargets-debug.

> 
> > The GrantleeConfig.cmake could set QT_USE_IMPORTED_TARGETS and a
> > find_package(Qt4) to recreated those imported targets.
> 
> Ok, so maybe setting QT_USE_IMPORTED_TARGETS is the thing that needs to be
> done 'again' by project B?

Yes, or preferably in your GrantleeConfig.cmake so project B doesn't have to do 
it.

> 
> So that means that yes, downstreams have to use QT_USE_IMPORTED_TARGETS if
> I do and can't use the path to the Qt libraries. From the Grantlee point
> of view the path to the libraries are not important, but it's relevant if
> it prevents downstreams from being able to use them.
> 
> >> 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).
> 
> In what way does CMake take care of the dependencies for me?
> 
> Do you mean that it takes care of automatically linking to the dependencies
> so that downstreams can do:
> 
> target_link_libraries(myApp
>   ${Grantlee_CORE_LIBRARIES}
> )
> 
> instead of
> 
> target_link_libraries(myApp
>   ${Grantlee_TEMPLATES_LIBRARIES}
>   ${QT_QTCORE_LIBRARIES}
> )
> 
> for example? Or do you mean something different?

Yeah, that is what I mean.

> 
> >> 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.
> 
> Hmm, I do use the QT_USE_FILE. I recently attempted to remove that
> add_definitions call and something failed (maybe it was plugin loading at
> runtime - I don't remember). I'll try again now and see if I can say what
> the problem is.

Ok.

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