QWindowsIntegrationPlugin/QWindowsDirect2DIntegrationPlugin can break static relocatable builds on Windows

Caused by: 548351

Before the above, UIAutomationCore.dll was loaded dynamically via:

QSystemLibrary uiaLib(QStringLiteral("UIAutomationCore"));

which worked since UIAutomationCore.dll should be present on every version of Windows that is supported.

548351 change the plugins so that they now use the Windows SDK to link to this via UIAutomationCore.lib, located via 

find_library 

which impacts the ability to relocate static builds.

When making a shared build, there is no issue as the compiler simply consumes UIAutomationCore.lib at Qt's build time, causing qwindows.dll to be linked to UIAutomationCore.dll, which is the easily resolved at application runtime since its a system library.

When making a static build of Qt, the absolute path of UIAutomationCore.lib, say

C:\Program Files (x86)\Windows Kits\10\Lib\10.0.20348.0\um\x64\UIAutomationCore.lib

is added to the plugins' INTERFACE_LINK_LIBRARIES, and not linked to until application build time. If that static relocatable build of Qt is then moved to another machine that has the Windows SDK installed to a different path, i.e.

C:\WinKits\10\Lib\10.0.20348.0

then the build fails with:

ninja: error: 'C:/Program Files (x86)/Windows Kits/10/Lib/10.0.20348.0/um/x64/UIAutomationCore.lib', needed by 'Release/CLIFp.exe', missing and no known rule to make it

I imagine this affects every build system and not just ninja.

I believe this is a well known complication with using static system libraries if they may be at different paths that is difficult to deal with.

I imagine there might be a way to abstract the dependency into a target/package such that the library can be located again at application build time (i.e. find_dependency()), in a similar manner to other system dependencies Qt relies on, though how to do so through the complexities of Qt's build system eludes me at the moment.

EDIT:

I believe since this is a system lib a simple way to do this is to specify it as a library link by just it's name like all of the other system libs that are in that same INTERFACE_LINK_LIBRARIES set and the linker will handle finding it. I didn't realize at first that UIAutomationCore could be handled the same way.

I'll submit a patch later.