Re: [Development] [Interest] Current status of the co-installation
On terça-feira, 30 de outubro de 2012 07.29.57, Koehne Kai wrote: > I stil don't like the qml2x convention too much. If you go through the list, > only qmlplugindump is both qtquick1 and qtquick2, so adding a '2' to all > the tools isn't necessary. > > ./lib64/qt5/bin/qml2bundle > ./lib64/qt5/bin/qml2min > > I'm pretty sure qml2min also works for qml1 files, so why not just stick to > qmlmin? It could even go to /usr/bin since it's not qt5 specific. Anyway, > since it's probably not that often used it's also okay to 'hide' it in > /lib64/qt5/bin... > > ./lib64/qt5/bin/qml2plugindump > ./lib64/qt5/bin/qml2profiler > > Same here, qmlprofiler actually works for both qml1 and qml2. I did it this way because I didn't know better. I erred in the side of caution: especially a tool that is talking about plugins, I assumed that it would try to load the plugins using the QML engine. And then I assumed that the other tools did similarly use the engine somehow. Now I'm hearing some interesting new information. If you tell me that a tool works for Qt Quick 1 and 2, then it can have the "2" dropped from its name. I just need a confirmation that it will stay that way. And yes, we can place it in the applications dir as well, if it's meant for users to run them too. > ./lib64/qt5/bin/qml2scene > > So why not stay with qmlscene here, if the qtquick1 one is still qmlviewer? To be honest, to keep consistency. All the QQ2 tools are "qml2" right now. But your new information might change that. > ./lib64/qt5/bin/qml2testrunner > ./lib64/qt5/bin/qmlplugindump > ./lib64/qt5/bin/qmlviewer > > Apart from the naming, is there a specific reason why qmlviewer, qml[2]scene > isn't in /usr/bin too? If you're asking me it's much more a 'user > application' then say lupdate. Haven't checked toolwrapper implementation > yet, is there a problem with adding these? There's no problem in adding those. It's quite easy, actually. For lupdate, I changed the .pro file and, at the end where it read: load(qt_tool) I changed to: load(qt_wrapped_tool) That's all. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Interest] Current status of the co-installation
I stil don't like the qml2x convention too much. If you go through the list, only qmlplugindump is both qtquick1 and qtquick2, so adding a '2' to all the tools isn't necessary. ./lib64/qt5/bin/qml2bundle ./lib64/qt5/bin/qml2min I'm pretty sure qml2min also works for qml1 files, so why not just stick to qmlmin? It could even go to /usr/bin since it's not qt5 specific. Anyway, since it's probably not that often used it's also okay to 'hide' it in /lib64/qt5/bin... ./lib64/qt5/bin/qml2plugindump ./lib64/qt5/bin/qml2profiler Same here, qmlprofiler actually works for both qml1 and qml2. ./lib64/qt5/bin/qml2scene So why not stay with qmlscene here, if the qtquick1 one is still qmlviewer? ./lib64/qt5/bin/qml2testrunner ./lib64/qt5/bin/qmlplugindump ./lib64/qt5/bin/qmlviewer Apart from the naming, is there a specific reason why qmlviewer, qml[2]scene isn't in /usr/bin too? If you're asking me it's much more a 'user application' then say lupdate. Haven't checked toolwrapper implementation yet, is there a problem with adding these? PS: Sorry for top-posting. From: development-bounces+kai.koehne=digia@qt-project.org [development-bounces+kai.koehne=digia@qt-project.org] on behalf of Thiago Macieira [thiago.macie...@intel.com] Sent: 29 October 2012 23:20 To: development@qt-project.org Subject: [Development] [Interest] Current status of the co-installation Hello again Here's the current status: * Qt Quick 1 and 2 de-conflicting: The Qt Quick 1 library is renamed and the patches are in. The library is called QtDeclarative again. Qt Quick 1 retains its import paths in QLibraryInfo::ImportsPath / $$[QT_INSTALL_IMPORTS], with no subdir. Qt Quick 2 instead goes to QLibraryInfo::Qml2ImportsPath / $$[QT_INSTALL_QML]. The patches for both pending, with a -1 from ossi due to an upcoming conflict with a new feature in mkspecs/features. I propose that the tools for Qt Quick 1 retain their exact naming from Qt 4 (qmlplugindump and qmlviewer). The tools from Qt Quick 2 should be prefixed with "qml2". Question: qml2scene or qml2viewer? If no one speaks up, it will be qml2scene. The patches for that are ready, pending approval. * Default paths: The defaults on a regular Unix or Windows installs are: -bindir$prefix/bin [unchanged] -libdir$prefix/lib [unchanged] -libexecdir$prefix/lib/qt5/libexec [new] -docdir[1] -headerdir $prefix/include -importdir $prefix/lib/qt5/imports [changed] -qmldir$prefix/lib/qt5/qml [new] -datadir $prefix/lib/qt5 [2] -translationdir$prefix/lib/qt5/translations [changed] -sysconfdir$prefix/etc/xdg [changed] -examplesdir $prefix/examples [unchanged] -testsdir $prefix/tests [unchanged] [1] docdir is $prefix/share/qt5/doc for installed builds, but remains $prefix/doc for non-installed builds as well as when qt.conf is found. Unless someone speaks in support of this staying, I am going to drop the patch. Linux distributions will change the dir to /usr/share/doc/qt5 anyway.. [2] for non-installed builds, datadir is $prefix, which makes the mkspecs be found at $prefix/mkspecs. The patches for all of the above are pending. There's a -1 on one patch because it probably breaks cross compilations from Linux to Windows -- considering I will not test this configuration, I will only fix it if someone sends me an exact patch of what to do. The patches that add libexecdir and qmldir have negative scores. The qmldir one has the -1 for the qml1_plugin.prf feature, whereas the libexec one has a -2 on disagreement on the principle. We need an agreement on the mailing list to decide what to do there. * Library names: All libraries get a 5 in their name in all platforms, except Mac when building frameworks. The 5 is placed after "Qt", so the libraries are now "libQt5Core.so" and "Qt5Core.dll", which makes for an unfortunate "Qt53D.dll" (but no more "QtV85.dll"). Patch is pending approval. * Tooling: The build for most tools is completely unchanged. For those, the ones that are from outside qtbase place themselves into the new libexec dir without changes. The ones in qtbase place themselves into bin, but install into libexec. A few tools I've modified to install into the bin dir. They are: assistant designer linguist macdeployqt makeqpf pixeltool qdbus qdbusviewer qtconfig (installs as qt5config) xmlpatterns xmlpatternsvalidator qglinfo They're all in qttools.git except for the two xmlpatterns tools and qglinfo. I've also added the wrapper tool, called "toolwrapper", which is *also* placed in the libexec dir. However, its install
Re: [Development] [Interest] Current status of the co-installation
On segunda-feira, 29 de outubro de 2012 18.51.10, Thiago Macieira wrote: > However, if you do a -prefix /usr configuration, then the layout will be: > > /usr/binUser applications only (qdbus, > linguist, etc.) /usr/liblibs > /usr/lib/cmake cmake files > /usr/lib/pkgconfig pkg-config files > /usr/lib/qt5/binTooling applications (moc, qmake, > etc.) /usr/lib/qt5/pluginsQt 5 plugins > /usr/lib/qt5/importsQML 1 imports > /usr/lib/qt5/qmlQML 2 imports > /usr/share/qt5/doc Qt 5 docs > /usr/share/qt5/translations Qt 5 translations > > If the distro passes --libdir=/usr/lib64, then the other arch-dependent > paths change accordingly. Here's a file listing of a build of almost all modules included in the SDK when configured with --prefix ~/qt5 --libdir ~/qt5/lib64. I've excluded the contents of the mkspecs, examples and include dirs for brevity. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ./bin/ ./bin/assistant ./bin/designer ./bin/lconvert -> /home/thiago/qt5/lib64/qt5/bin/toolwrapper ./bin/linguist ./bin/lrelease -> /home/thiago/qt5/lib64/qt5/bin/toolwrapper ./bin/lupdate -> /home/thiago/qt5/lib64/qt5/bin/toolwrapper ./bin/pixeltool ./bin/qdbus ./bin/qdbusviewer ./bin/qglinfo ./bin/qmake -> /home/thiago/qt5/lib64/qt5/bin/toolwrapper ./bin/xmlpatterns ./bin/xmlpatternsvalidator ./examples/ ./examples/qtbase/ ./examples/qtdeclarative/ ./examples/qtquick/ ./examples/qtscript/ ./examples/qtsvg/ ./examples/qtxmlpatterns/ ./include/ ./include/Qt/ ./include/Qt3D/ ./include/Qt3DQuick/ ./include/Qt5Core/ ./include/QtCLucene/ ./include/QtConcurrent/ ./include/QtCore/ ./include/QtDBus/ ./include/QtDeclarative/ ./include/QtDesigner/ ./include/QtDesignerComponents/ ./include/QtGui/ ./include/QtHelp/ ./include/QtNetwork/ ./include/QtOpenGL/ ./include/QtPlatformSupport/ ./include/QtPrintSupport/ ./include/QtQml/ ./include/QtQmlDevTools/ ./include/QtQuick/ ./include/QtQuickParticles/ ./include/QtQuickTest/ ./include/QtScript/ ./include/QtScriptTools/ ./include/QtSensors/ ./include/QtSql/ ./include/QtSvg/ ./include/QtTest/ ./include/QtUiTools/ ./include/QtV8/ ./include/QtWebKitWidgets/ ./include/QtWidgets/ ./include/QtXml/ ./include/QtXmlPatterns/ ./lib64/ ./lib64/cmake/ ./lib64/cmake/Qt53D/ ./lib64/cmake/Qt53D/Qt53DConfig.cmake ./lib64/cmake/Qt53D/Qt53DConfigVersion.cmake ./lib64/cmake/Qt53DQuick/ ./lib64/cmake/Qt53DQuick/Qt53DQuickConfig.cmake ./lib64/cmake/Qt53DQuick/Qt53DQuickConfigVersion.cmake ./lib64/cmake/Qt5Concurrent/ ./lib64/cmake/Qt5Concurrent/Qt5ConcurrentConfig.cmake ./lib64/cmake/Qt5Concurrent/Qt5ConcurrentConfigVersion.cmake ./lib64/cmake/Qt5Core/ ./lib64/cmake/Qt5Core/Qt5CoreConfig.cmake ./lib64/cmake/Qt5Core/Qt5CoreConfigExtras.cmake ./lib64/cmake/Qt5Core/Qt5CoreConfigVersion.cmake ./lib64/cmake/Qt5Core/Qt5CoreMacros.cmake ./lib64/cmake/Qt5Core/Qt5CTestMacros.cmake ./lib64/cmake/Qt5DBus/ ./lib64/cmake/Qt5DBus/Qt5DBusConfig.cmake ./lib64/cmake/Qt5DBus/Qt5DBusConfigExtras.cmake ./lib64/cmake/Qt5DBus/Qt5DBusConfigVersion.cmake ./lib64/cmake/Qt5DBus/Qt5DBusMacros.cmake ./lib64/cmake/Qt5Declarative/ ./lib64/cmake/Qt5Declarative/Qt5DeclarativeConfig.cmake ./lib64/cmake/Qt5Declarative/Qt5DeclarativeConfigVersion.cmake ./lib64/cmake/Qt5Designer/ ./lib64/cmake/Qt5Designer/Qt5DesignerConfig.cmake ./lib64/cmake/Qt5Designer/Qt5DesignerConfigVersion.cmake ./lib64/cmake/Qt5Gui/ ./lib64/cmake/Qt5Gui/Qt5GuiConfig.cmake ./lib64/cmake/Qt5Gui/Qt5GuiConfigVersion.cmake ./lib64/cmake/Qt5Help/ ./lib64/cmake/Qt5Help/Qt5HelpConfig.cmake ./lib64/cmake/Qt5Help/Qt5HelpConfigVersion.cmake ./lib64/cmake/Qt5LinguistTools/ ./lib64/cmake/Qt5LinguistTools/Qt5LinguistToolsConfig.cmake ./lib64/cmake/Qt5LinguistTools/Qt5LinguistToolsMacros.cmake ./lib64/cmake/Qt5Network/ ./lib64/cmake/Qt5Network/Qt5NetworkConfig.cmake ./lib64/cmake/Qt5Network/Qt5NetworkConfigVersion.cmake ./lib64/cmake/Qt5OpenGL/ ./lib64/cmake/Qt5OpenGL/Qt5OpenGLConfig.cmake ./lib64/cmake/Qt5OpenGL/Qt5OpenGLConfigVersion.cmake ./lib64/cmake/Qt5PrintSupport/ ./lib64/cmake/Qt5PrintSupport/Qt5PrintSupportConfig.cmake ./lib64/cmake/Qt5PrintSupport/Qt5PrintSupportConfigVersion.cmake ./lib64/cmake/Qt5Qml/ ./lib64/cmake/Qt5Qml/Qt5QmlConfig.cmake ./lib64/cmake/Qt5Qml/Qt5QmlConfigVersion.cmake ./lib64/cmake/Qt5Quick/ ./lib64/cmake/Qt5Quick/Qt5QuickConfig.cmake ./lib64/cmake/Qt5Quick/Qt5QuickConfigVersion.cmake ./lib64/cmake/Qt5QuickTest/ ./lib64/cmake/Qt5QuickTest/Qt5QuickTestConfig.cmake ./lib64/cmake/Qt5QuickTest/Qt5QuickTestConfigVersion.cmake ./lib64/cmake/Qt5Script/ ./lib64/cmake/Qt5Script/Qt5ScriptConfig.cmake ./lib64/cmake/Qt5Script/Qt5ScriptConfigVersion.cmake ./lib64/cmake/Qt5ScriptTools/ ./lib64/cmake/Qt5ScriptTools/Qt5ScriptToolsConfig.cmake ./lib64/cmake/Qt5ScriptTools/Qt5ScriptToolsConfigVersion.cmake ./lib64/cmake/Qt5Sensors/ ./l
Re: [Development] [Interest] Current status of the co-installation
On segunda-feira, 29 de outubro de 2012 15.20.20, Thiago Macieira wrote: > * Default paths: > The defaults on a regular Unix or Windows installs are: > -bindir$prefix/bin [unchanged] > -libdir$prefix/lib [unchanged] > -libexecdir$prefix/lib/qt5/libexec [new] > -docdir[1] > -headerdir $prefix/include > -importdir $prefix/lib/qt5/imports [changed] > -qmldir$prefix/lib/qt5/qml [new] > -datadir $prefix/lib/qt5 [2] > -translationdir$prefix/lib/qt5/translations [changed] > -sysconfdir$prefix/etc/xdg [changed] > -examplesdir $prefix/examples [unchanged] > -testsdir $prefix/tests [unchanged] I've updated the patches for this and consolidated into three changes only, plus the controversial one that adds libexecdir. I've also made some changes that should hopefully address some of the concerns that have been raised along the way. Here are the defaults after my changes: -bindir PREFIX/bin [unchanged] -headerdir PREFIX/include [unchanged] -libdir PREFIX/lib [unchanged] -archdatadirLIBDIR/qt5 or PREFIX [new] [1] -libexecdir ARCHDATADIR/bin [new] -plugindir ARCHDATADIR/plugins [1] -importdir ARCHDATADIR/imports [1] -qmldir ARCHDATADIR/qml [new] -datadirPREFIX/share/qt5 or PREFIX [changed] [1] -docdir DATADIR/doc [1] -translationdir DATADIR/translations [1] -sysconfdir PREFIX/etc/xdg [1] -examplesdirPREFIX/examples [unchanged] -testsdir PREFIX/tests[unchanged] mkspecs ARCHDATADIR/mkspecs [1] [1] archdata and data have two defaults: either PREFIX or something else. They default to PREFIX whenever -prefix is $PWD, which happens on Windows and when you select that option (including via -developer-build). Also, when a qt.conf file is found, QLibraryInfo makes everything relative to that file's parent dir and defaults to a standard layout. The net effect is that for most people on this list, *nothing* changes. That is, if you configure qtbase with -prefix $PWD, you're going to have: qtbase/bin *all* executables, because $bindir = $libexecdir qtbase/lib libs qtbase/lib/cmakecmake files qtbase/lib/pkgconfigpkg-config files qtbase/plugins Qt 5 plugins qtbase/imports QML 1 imports qtbase/qml QML 2 imports qtbase/doc Qt 5 docs qtbase/translations Qt 5 translations However, if you do a -prefix /usr configuration, then the layout will be: /usr/binUser applications only (qdbus, linguist, etc.) /usr/liblibs /usr/lib/cmake cmake files /usr/lib/pkgconfig pkg-config files /usr/lib/qt5/binTooling applications (moc, qmake, etc.) /usr/lib/qt5/pluginsQt 5 plugins /usr/lib/qt5/importsQML 1 imports /usr/lib/qt5/qmlQML 2 imports /usr/share/qt5/doc Qt 5 docs /usr/share/qt5/translations Qt 5 translations If the distro passes --libdir=/usr/lib64, then the other arch-dependent paths change accordingly. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Interest] Current status of the co-installation
On terça-feira, 30 de outubro de 2012 10.12.02, Chris Adams wrote: > qml2scene makes more sense than qml2viewer, in my opinion. Thanks, that means I don't need to change anything. It also helps in Qt Creator because it knows that Qt Quick 2 = scene and Qt Quick 1 = viewer. > I've added some comments to various reviews, although I'm slightly confused > about what the current plan is with respect to 37104 vs 38300 for example. > The only one I have an issue with, really, is the rename of the environment > variable to QML2_IMPORT_PATH - purely from a consistency perspective with > the other envvars like QML_COMPILER_STATS and so forth. > > I've added Martin as reviewer to most of them, to see if he has any issue > with any of the changes, also. Qt least the import path variable needs to be disambiguated because they refer to different hierarchies. We don't want Qt Quick 2 loading Qt Quick 1 plugins. As for the other variables, I'm all ears: do you prefer to rename them all or keep some with the same name as in Qt Quick 1? As for 38300, that's not a change of mine. Ossi is introducing a qml1_plugin.prf feature to qmake which makes creating Qt Quick 1 plugins easier, but he's introducing them without the changes I've proposed in this email. His changes conflict with mine, so one of the two of us will need to adapt and rebase. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Interest] Current status of the co-installation
Hi, [snip] > Question: qml2scene or qml2viewer? If no one speaks up, it will be > qml2scene. > The patches for that are ready, pending approval. > [snip] > > The relevant changes are: > Qt Quick 1 & 2: > https://codereview.qt-project.org/37104 (QQ1's imports with no > subdir) > https://codereview.qt-project.org/37242 (adds -qmldir) > https://codereview.qt-project.org/37431 (renames qml1plugindump > back) > https://codereview.qt-project.org/37434 (renames QQ2 tools to > qml2*) > https://codereview.qt-project.org/37539 (use the Qml2ImportPath) > https://codereview.qt-project.org/35521 (changes QQ2 examples dir) > https://codereview.qt-project.org/36711 (doc update about the > examples) > https://codereview.qt-project.org/37555 (updates Qt Creator) > [snip] qml2scene makes more sense than qml2viewer, in my opinion. I've added some comments to various reviews, although I'm slightly confused about what the current plan is with respect to 37104 vs 38300 for example. The only one I have an issue with, really, is the rename of the environment variable to QML2_IMPORT_PATH - purely from a consistency perspective with the other envvars like QML_COMPILER_STATS and so forth. I've added Martin as reviewer to most of them, to see if he has any issue with any of the changes, also. Cheers, Chris. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [Interest] Current status of the co-installation
Hello again Here's the current status: * Qt Quick 1 and 2 de-conflicting: The Qt Quick 1 library is renamed and the patches are in. The library is called QtDeclarative again. Qt Quick 1 retains its import paths in QLibraryInfo::ImportsPath / $$[QT_INSTALL_IMPORTS], with no subdir. Qt Quick 2 instead goes to QLibraryInfo::Qml2ImportsPath / $$[QT_INSTALL_QML]. The patches for both pending, with a -1 from ossi due to an upcoming conflict with a new feature in mkspecs/features. I propose that the tools for Qt Quick 1 retain their exact naming from Qt 4 (qmlplugindump and qmlviewer). The tools from Qt Quick 2 should be prefixed with "qml2". Question: qml2scene or qml2viewer? If no one speaks up, it will be qml2scene. The patches for that are ready, pending approval. * Default paths: The defaults on a regular Unix or Windows installs are: -bindir$prefix/bin [unchanged] -libdir$prefix/lib [unchanged] -libexecdir$prefix/lib/qt5/libexec [new] -docdir[1] -headerdir $prefix/include -importdir $prefix/lib/qt5/imports [changed] -qmldir$prefix/lib/qt5/qml [new] -datadir $prefix/lib/qt5 [2] -translationdir$prefix/lib/qt5/translations [changed] -sysconfdir$prefix/etc/xdg [changed] -examplesdir $prefix/examples [unchanged] -testsdir $prefix/tests [unchanged] [1] docdir is $prefix/share/qt5/doc for installed builds, but remains $prefix/doc for non-installed builds as well as when qt.conf is found. Unless someone speaks in support of this staying, I am going to drop the patch. Linux distributions will change the dir to /usr/share/doc/qt5 anyway.. [2] for non-installed builds, datadir is $prefix, which makes the mkspecs be found at $prefix/mkspecs. The patches for all of the above are pending. There's a -1 on one patch because it probably breaks cross compilations from Linux to Windows -- considering I will not test this configuration, I will only fix it if someone sends me an exact patch of what to do. The patches that add libexecdir and qmldir have negative scores. The qmldir one has the -1 for the qml1_plugin.prf feature, whereas the libexec one has a -2 on disagreement on the principle. We need an agreement on the mailing list to decide what to do there. * Library names: All libraries get a 5 in their name in all platforms, except Mac when building frameworks. The 5 is placed after "Qt", so the libraries are now "libQt5Core.so" and "Qt5Core.dll", which makes for an unfortunate "Qt53D.dll" (but no more "QtV85.dll"). Patch is pending approval. * Tooling: The build for most tools is completely unchanged. For those, the ones that are from outside qtbase place themselves into the new libexec dir without changes. The ones in qtbase place themselves into bin, but install into libexec. A few tools I've modified to install into the bin dir. They are: assistant designer linguist macdeployqt makeqpf pixeltool qdbus qdbusviewer qtconfig (installs as qt5config) xmlpatterns xmlpatternsvalidator qglinfo They're all in qttools.git except for the two xmlpatterns tools and qglinfo. I've also added the wrapper tool, called "toolwrapper", which is *also* placed in the libexec dir. However, its install rule will create a symlink to itself as $bindir/qmake. This tool is bootstrapped and unit-tested. It's inside qtbase. I decided against modifying qmake because it was way too complex. All the patches are pending approval, except for the one that creates libexec (-2 from ossi). The relevant changes are: Qt Quick 1 & 2: https://codereview.qt-project.org/37104 (QQ1's imports with no subdir) https://codereview.qt-project.org/37242 (adds -qmldir) https://codereview.qt-project.org/37431 (renames qml1plugindump back) https://codereview.qt-project.org/37434 (renames QQ2 tools to qml2*) https://codereview.qt-project.org/37539 (use the Qml2ImportPath) https://codereview.qt-project.org/35521 (changes QQ2 examples dir) https://codereview.qt-project.org/36711 (doc update about the examples) https://codereview.qt-project.org/37555 (updates Qt Creator) Default paths: https://codereview.qt-project.org/37252 (requirement, breaks Mac build and I need help) https://codereview.qt-project.org/37244 (changes datadir) https://codereview.qt-project.org/35495 (change plugindir, importsdir, translationsdir and settingsdir) https://codereview.qt-project.org/37253 (docdir change, I'll abandon) Library names with 5: https://codereview.qt-project.org/37256 Tooling: https://codereview.qt-project.org/38223 (qglinfo) https://codereview.qt-project.org/38224 (xmlpatterns*) https://codereview.qt-project.org/38464 (qt5config)
