Qt5 component library not copied to CMAKE_RUNTIME_OUTPUT_DIRECTORY

Code
1

Under Windows, CMake sees the following:

set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/bin/$<CONFIG>)
find_package(Qt5 REQUIRED COMPONENTS Core Gui Widgets Network Concurrent)
target_link_libraries(mylib
    PRIVATE
    ${Qt5Network_LIBRARIES}
    ${Qt5Gui_LIBRARIES}
    ${Qt5Widgets_LIBRARIES}
    ${Qt5Core_LIBRARIES}
    )

After cmake, cmake --build, we get a directory ...\build\bin\Release that contains Qt5Widgets.dll but not Qt5Network.dll.

What may be going wrong? How to debug?

2

First off, try changing the variable references to imported targets to ensure you’re not getting empty variables:

target_link_libraries(mylib
    PRIVATE
    Qt5::Network
    Qt5::Gui
    Qt5::Widgets
    Qt5::Core
    )

If any of those targets don’t exist, you will get an error. If it succeeds, see if Qt5Network.dll is still missing.

3

Syntax change made, problem persists: Qt5Network.dll still missing in bin\Release.

4

I compared the files Qt5Network/Qt5NetworkConfig.cmake and Qt5Widgets/Qt5WidgetsConfig.cmake. Besides the trivial substitution “Network” -> “Widgets” and a few references to functions from the respective libraries, there is just one big difference: Qt5WidgetsConfig.cmake has the lines

include("${CMAKE_CURRENT_LIST_DIR}/Qt5WidgetsConfigExtras.cmake")
include("${CMAKE_CURRENT_LIST_DIR}/Qt5WidgetsMacros.cmake")

which have no equivalent in Qt5NetworkConfig.cmake. Is this intentional? If so, why? Could it nonetheless be the unintended cause of my DLL problem?

5

Doubt it. Both of those files are the Qt framework asking each component “I’ve exported all of your targets in CMake. Do you have anything else to put into CMake?” It seems that for Qt5Widgets the answer is “yes”, but for Qt5Network the answer is “no”. But Qt5Network should still have the imported target.

6

Kyle, I’m still puzzled by your latest response. Sounds really close to the decisive point, but too arcane for me to follow. Could you possibly elaborate a bit?

Also, I am no longer sure whether the anomaly is the absence of Qt5Network, or rather the presence of the three other libraries. Would CMake by default copy any DLL dependence to CMAKE_RUNTIME_OUTPUT_DIRECTORY?

7

Some of the modules in Qt export extra CMake macros, configuration variables, etc. These have to be placed in Qt5<module>ConfigExtras.cmake and Qt5<module>Macros.cmake. However, not all of them do, and the ones that don’t, don’t get these files included in their Qt5<module>Config.cmake. That’s why you’re seeing that diff, and I don’t think it has anything to do with why Qt5Network isn’t getting copied in.

Here’s a shot in the dark: try moving Qt5::Network to the end of the list and see if you get the same result.

8

I’m more curious why Qt5Widgets.dll is being copied into the CMAKE_RUNTIME_OUTPUT_DIRECTORY. What is causing that to be done?

9

Indeed, the strange behavior is the copying of Qt5Widgets.dll etc.

By bisectioning my real application, I found out that it is caused not by the code communicated in my original post, but by an obscure PackIFW script that calls windeployqt.exe.

Sorry.