[qt5]: QLibraryInfo doesn't get installed paths

[huangqinjin]

Paths returned by QLibraryInfo are all under %VCPKG_ROOT%\packages other than %VCPKG_ROOT%\installed. Consider overwrite qt_prfxpath in Qt5Core.dll binary. Seems the Qt online installer did this.

In my case:

$ strings Qt5Core.dll | grep qt_prfxpath
qt_prfxpath=C:/Users/huangqinjin/vcpkg/packages/qt5-base_x64-windows

[glachancecmaisonneuve]

Before we start patching the tools left and right, I would like to chime in and report that almost all of the functionality of all qt5 tools can be restored by simply adding a qt.conf file in the tools own folder. It's a superior solution to patching because: 1- It's a lot less work & more stable 2- It works in the use-case scenario of someone using an exported qt5-tools package.

This is what I have been using:

[Paths]
Prefix = ../..
Documentation = share/qt5/doc
Headers = include
Libraries = lib
Binaries = tools/qt5
LibraryExecutables = tools/qt5
Plugins = plugins
Qml2Imports = qml
Data = share/qt5
ArchData = share/qt5
HostData = share/qt5
HostBinaries = tools/qt5-tools
HostLibraries = lib
Translations = share/qt5/translations

ref: https://github.com/Microsoft/vcpkg/pull/2892

[glachancecmaisonneuve]

@huangqinjin You did not mention the tool you are using and the usage context (was the tool moved after compilation). Could you try adding a file called qt.conf (with the content as described above) to the tool's folder and report if the tool actually needs patching or not. Also, if you can, try the tool in the installed folder as well as the packages folder.

[huangqinjin]

Just a naive qml application complain that module "QtQuick" is not installed. In fact, there is a qt_debug.conf installed as well as qmake.exe. I copy the file to application folder and rename to qt.conf (Prefix in the file should be substituted by cmake, that seems a port bug) , and it works.

[glachancecmaisonneuve]

Thank you for taking the time to test this out.

qt_debug.conf should probably be moved elsewhere. Along with qt_release.conf, it is used to compile the tools in buildtrees, and then again to install to packages. It has zero impact on the installed tools.

Adding the qt.conf (the one with prefix=../..) that allows your qml app to work correctly is the fix I am proposing. I made a PR https://github.com/Microsoft/vcpkg/pull/2892 yesterday to that end.

[huangqinjin]

But for developing rather than using qt tools, I need to copy qt.conf to the build folder every time. I think it's good that correct the qt_debug.conf and qt_release.conf and use them as templates.

[glachancecmaisonneuve]

Lets get a few keywords down so we can understand each other.

I copy the file to application folder and rename to qt.conf

I think what you mean here instead of application folder is the tool folder. A tool is an executable developed by Qt (the org) and the most popular ones are: qmake, aml, designer, linguist, winqtdeploy, etc. The tool folder is it's location. For vcpkg that means VCPKG_ROOT_DIR/installed/VCPKG_TRIPLET/tool/...

If you are in fact building your own application inside a tool folder, then you are doing it wrong. Well, not wrong exactly, you can do that if you want I guess, but typically people want to build in a separate folder, outside the vcpkg tree altogether, for example this would be more common:

• c:\vcpkg\installed\x64-windows\tools\qt5\qmake.exe (this is where you put qt.conf)
• c:\vcpkg\installed\x64-windows\tools\qt5\qt.conf
• c:\mypersonalproject\myqmlapp

the you build with

cd /d c:\mypersonalproject\myqmlapp
c:\vcpkg\installed\x64-windows\tools\qt5\qmake.exe -makefile -recursive CONFIG+=release ....

once built, if you want to use myqmlapp independantly of qt, you need to deploy the qt libraries with qtdeploy.ps1.

to reiterate, you are not supposed to install a qt.conf file inside the folder myqmlapp.

[huangqinjin]

I don't use the tools explicitly, what I did were writing a simple qmlapp in visual studio 2017 with cmake, then F5 to debug it. It's the developing stage rather than deploying. I do know how to deploy a qt app -- just copy all dependencies, including dlls and qmls, to app folder.

[glachancecmaisonneuve]

Give me a bug description and the instructions I need to reproduce.

[huangqinjin]

@glachancecmaisonneuve please open the project in visual studio 2017, use Open Folder. https://github.com/huangqinjin/CMakeQt/tree/2e19ddb6b3ac71e30ba922dd61851aa8dbd183ae

[glachancecmaisonneuve]

sorry I meant to come back to this thread a lot sooner. and thank you for the example. So you are right, the cmake macros are not functional at this time.

If you still want to use vcpkg's qt in your build setup, qmake, qdesigner and the rest are currently usable (with the patch I provided).

[huangqinjin]

3280 has fixed some paths except for qmldir. mklink /D qml ..\qml in${CURRENT_INSTALLED_DIR}/debug fixes it.

[ras0219-msft]

Ok, so after a bunch of investigation and discussion with the guys over at Qt, I've made the following key changes:

• We now generate a blank qt.conf file when deploying QtCore*.dll. This actually causes Qt to look in the applocal directory for qml files and plugins, ignoring all hard coded paths!
  • Note that if you already create your own qt.conf during cmake configure time, we won't overwrite it.
• We deploy qml files; currently we deploy all qml bits that are currently available -- in the future we can look into trying to slim this down via more intelligent analysis
• Qml files are now built into separate directories for release and debug (qml/ and debug/qml). We only deploy the right one, which helps keep the deploy size down.
• We also deploy the QtQuickcontrols binaries while deploying QtQuick, which removes the need for the last section in @huangqinjin's awesome repro project 👍

With these changes, I'm able to directly open @huangqinjin's project and (after removing the qtquickcontrols deploy code at the bottom) f5 out of the box!

@claudiofantacci for review/input and thanks @glachancecmaisonneuve for digging in with the investigation :). Finally, also thanks to @tronical for actually knowing how all this stuff works to figure out the right answer!

[huangqinjin]

@ras0219-msft , I got

-- Performing post-build validation
There should be no empty directories in C:/Users/huangqinjin/vcpkg/packages/qt5-declarative_x64-windows
The following empty directories were found:

    C:/Users/huangqinjin/vcpkg/packages/qt5-declarative_x64-windows/tools/qt5-declarative/plugins/platforminputcontexts

[huangqinjin]

I added file(REMOVE_RECURSE) to qt5-declarative\portfile.cmake and qt5-tools\portfile.cmake to solve the post-build validation problem. But it's ok if I git clone vcpkg to somewhere else and install qt5.

For a QtWidget application, which doesn't depend on QtQuick/qml, qml relatives are also deployed.

[claudiofantacci]

I added file(REMOVE_RECURSE) to qt5-declarative\portfile.cmake and qt5-tools\portfile.cmake to solve the post-build validation problem. But it's ok if I git clone vcpkg to somewhere else and install qt5.

So this is a regression from previous installation. Am I right?

[huangqinjin]

May be and I don’t know how to cleanup.

[jsutes]

@ras0219-msft I recently updated my local vcpkg repo and discovered my application install process is now putting qwindows.dll in install_dir/plugins/platforms/qwindows.dll instead of install_dir/platforms/qwindows.dll When starting my application, I now get an error window saying "This application failed to start because no Qt platform plugin could be initialized." If I manually remove the "plugins" part of the path, then my application starts without the error. I believe I traced down the change in behavior to this issue and the change to qtdeploy.ps1 around line 37. Why was this change made? It seems to break my workflow. I don't use qt.conf, qml, or qtquick which are all mentioned in the commit title.