[CMake] Where is QT_USE_IMPORTED_TARGETS not safe to use?

Stephen Kelly steveire at gmail.com
Tue Jun 21 08:59:25 EDT 2011


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?

> 
> 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?

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?

>> 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.

Thanks for answers and patience. I tend to dislike magic, so I want to 
understand all of this stuff before I actually apply it.

Steve.




More information about the CMake mailing list