[cmake-developers] Generating imported library targets without the cmake executable

[Alexander Neundorf]

On Thursday 24 November 2011, Stephen Kelly wrote:
> Hi there,
> 
> I am working on installing CMake config files from the Qt repository so
> that there is less need for a FindQt.cmake.
> 
> The motivation is that between releases of Qt and CMake, the features of Qt
> get out of sync with the features available through FindQt.cmake, but with
> config files that is not the case. Additionally, as the Qt buildsystem
> knows everything about the package it is creating, it is possible to
> create config files that already 'know the answers' and locations of
> everything without having to find+query.
> 
> The previous discussion on this is here:
> 
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/2090
> 
> the current candidate for inclusion in Qt is here (which requires an
> account in the Qt jira):
> 
> http://codereview.qt-project.org/#change,8518
> 
> and here (which does not):
> 
> https://qt.gitorious.org/+kdab-developers/qt/kdab-developers-
> qtbase/commit/913fd3a1acffbae2ca8f6967dd951a03ff9f76a4
> 
> There is a small sticking point to this being in a finished state:
> 
> In creating the imported targets, I attempt to create the same content as
> cmake creates when using install(EXPORTS). So I generate something along
> these lines:
> 
> get_filename_component(_qt5_install_prefix
>                        ${CMAKE_CURRENT_LIST_DIR}/../../../ ABSOLUTE)
> 
> set_property(TARGET Qt5Core APPEND PROPERTY IMPORTED_CONFIGURATIONS DEBUG)
> set_target_properties(Qt5Core PROPERTIES
>     IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG ""
>     IMPORTED_LOCATION_DEBUG "${_qt5_install_prefix}/lib/libQtCore.so.5.0.0"
>     IMPORTED_SONAME_DEBUG "libQtCore.so.5"
> )
> 
> set_property(TARGET Qt5Core APPEND PROPERTY IMPORTED_CONFIGURATIONS
> RELEASE) set_target_properties(Qt5Core PROPERTIES
>     IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE ""
>     IMPORTED_LOCATION_RELEASE
>                             "${_qt5_install_prefix}/lib/libQtCore.so.5.0.0"
>     IMPORTED_SONAME_RELEASE "libQtCore.so.5"
> )
> 
> 
> That is, I generate the full file name for the IMPORTED_LOCATION including
> the library prefix and suffix, which are also used for the IMPORTED_SONAME.
> QMake does not provide the library prefix and suffix used in variables, as
> cmake does, but I believe there is also no way to change them in qmake. As
> a result I hardcode the prefixes and suffixes for windows/linux/max -
> .dll, .so etc.
> 
> The Qt QMake maintainer does not like this, and requests that CMake
> determines the prefix and suffix instead. Does CMake provide any way for me
> to get the default prefix and suffix for libraries? If it does then I could
> generate something like this instead:
> 
> IMPORTED_SONAME "${CMAKE_LIBRARY_PREFIX}QtCore.${CMAKE_LIBRARY_SUFFIX}.5"

It's CMAKE_(STATIC|SHARED)_LIBRARY_(SUFFIX|PREFIX) .

> But I still don't think it's necessarily a good idea or the right change to
> make. QMake and CMake don't necessarily agree on what the prefix and suffix
> for libraries will be on different platforms for one thing.

Yes, it would be the wrong source of information. This information must come 
from the one who creates libraries, not from the one who wants to know how 
they are named.

> What would you consider a good idea?
> 
> Could this have any implications for cross-compiling?
> 
> Currently I generate IMPORTED_CONFIGURATIONS for debug and release
> (conditionally, depending on how Qt is built). Should I also generate code
> to set target properties for no configuration? Or should I only do that,
> and not have debug/release versions?:

Having a debug configuration is a good thing I'd say.
Additionally having a release or noconfig version should be fine.

Alex