Re: [Development] Enorcing QT_SKIP_AUTO_[QML_]PLUGIN_INCLUSION
> On 3. Jul 2023, at 16:50, Lisandro Damián Nicanor Pérez Meyer > wrote: > > El lunes, 3 de julio de 2023 11:47:44 -03 Lisandro Damián Nicanor Pérez Meyer > escribió: > [snip] >> So far it has worked, but of course I'll have more feedback later on :-) > > > I just built 5.6.1 as shared libraries and all the ".a" files created are > libraries and not plugins Qt 5.6-5.15 don't ship static plugins when doing a shared Qt build. That's a new addition in Qt 6. An example of an always static plugin is the darwin permissions plugin, but that's not relevant for linux. More might be added in the future. > (the file you mentioned is not even there). So far that's just safe. The files I mentioned were just hypothetical examples, they don't exist yet. Although they did exist as a proof of concept WIP change on Gerrit. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Enorcing QT_SKIP_AUTO_[QML_]PLUGIN_INCLUSION
> On 3. Jul 2023, at 16:47, Lisandro Damián Nicanor Pérez Meyer > wrote: > > Now the question is: is the CMake file used to only check for it's presence > or will designer fail to load the static file? If the CMake file is present, but not loaded (via an explicit find_package call or transitively through another find_package call), building Designer will fail at cmake configure time. That would happen in the hypothetical case where qttools/src/tools/designer/CMakeLists.txt has: target_link_libraries(Designer PRIVATE Qt6::QIconsPlugin) If you set QT_SKIP_AUTO_PLUGIN_INCLUSION to ON, CMake will error out saying "unknown target Qt6::QIconsPlugin", even if the file exists and is installed as part of qt6-qtbase-dev. Adding find_package(Qt6 COMPONENTS IconsPlugin) before the target_link_libraries call would fix it. While I agree it's generally a good idea to be more granular and explicit with these kind of dependencies, e.g. to specify find_package calls only in subdirectories of targets that need them, in practice CMake target / directory scoping rules often cause obscure issues. Which is why we autoload all plugins in the root CMakeLists.txt where the initial find_package(Qt6) call is done. This provides ease of use for regular Qt builders (not distros) and avoids the cmake scoping issues. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Enorcing QT_SKIP_AUTO_[QML_]PLUGIN_INCLUSION
El lunes, 3 de julio de 2023 11:47:44 -03 Lisandro Damián Nicanor Pérez Meyer escribió: [snip] > So far it has worked, but of course I'll have more feedback later on :-) I just built 5.6.1 as shared libraries and all the ".a" files created are libraries and not plugins (the file you mentioned is not even there). So far that's just safe. signature.asc Description: This is a digitally signed message part. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Enorcing QT_SKIP_AUTO_[QML_]PLUGIN_INCLUSION
El lunes, 3 de julio de 2023 10:49:43 -03 Alexandru Croitor escribió: > > > On 3. Jul 2023, at 15:29, Lisandro Damián Nicanor Pérez Meyer > > wrote: > > > > Hi! > > > > El lunes, 3 de julio de 2023 05:26:11 -03 Alexandru Croitor escribió: > >>> On 30. Jun 2023, at 20:04, Lisandro Damián Nicanor Pérez Meyer > >>> wrote: > > [snip] > >>> I recently noted the CMake variables QT_SKIP_AUTO_PLUGIN_INCLUSION and > >>> QT_SKIP_AUTO_QML_PLUGIN_INCLUSION, which default to undefined. > >>> > >>> If I understand correctly the CMake file for searching for plugins are > >>> there because: > >>> > >>> - One needs to find them when doing a static build in order to add them > >>> to the final static object. > >>> - One might use it to find the plugins and copy them when bundling > >>> applications. > >> > >> That's right. > >> > >> For static plugins, the loading of plugin Config files and the > >> availability of the cmake targets is needed for final linking purposes and > >> also at configure time for running qmlimportscanner, and other qml tooling. > >> For shared plugins, the targets are needed for deployment / bundling > >> purposes (so runtime deps). > >> > >> One particular case which I'm not sure if it's used right now, but was > >> brought up in various (private) discussions, is creating static qt plugins > >> in a shared qt build. > >> In a more recent discussion, it was about providing a static plugin > >> containing just image assets. > > > > Perfect, so my understanding was more or less correct. So far none of the > > above are use cases expected for a distro build. > > > >> Depending on what the plugin is linked to in the end, for example a qt > >> tool in another repo, the plugin target would need to exist at build time, > >> and thus the config files loaded. > >> In this case, even a distro would have to load the file. > > > > And that would be a runtime dependency the tool has on the plugin, which is > > just OK. If done properly that plugin will be installed due to packaging > > dependencies. > > > > I don't think that's a runtime dependency, it's a build time dependency, > hence the Config files need to be loaded. > > To summarize the hypothetical case: > > qtbase is shared Qt build, so libQt6Gui.so, etc > > qtbase/src/plugins/icons/libqicons.a is a static qt plugin, even though Qt is > a shared build. It belongs to the Gui module. > > qttools/src/tools/designer is an app. It needs to link to libqicons.a at > build time. > > The qttools/src/tools/designer/CMakeLists.txt will refer to it via a CMake > Target name e.g Qt6::QIconsPlugin, hence the Qt6IconsPluginConfig.cmake > package needs to be found and loaded. > That would usually be done automatically via the find_package(Qt6 COMPONENTS > Gui) call because the default is to load all plugin config files. Well, any static file (*.a) created as part of a shared lib build is considered a development file, thus packages into qt--dev. In this case qtbase, so qt6-base-dev, which will be installed for any submodule requiring to build with Qt, so the file will be present. Now the question is: is the CMake file used to only check for it's presence or will designer fail to load the static file? > I suppose if the automatic loading is disabled, we can be explicit and add a > find_package(Qt6 COMPONENTS IconsPlugin) in > qttools/src/tools/designer/CMakeLists.txt and it would still work in your > distro case. That would actually be ideal, because it decouples a _real_ build dependency with just the fact of checking a plugin is there. > So TLDR, should be safe for your to disable the automatic loading of plugins > during a shared Qt distro build atm. So far it has worked, but of course I'll have more feedback later on :-) signature.asc Description: This is a digitally signed message part. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Meeting minutes from Qt Release Team meeting 20.06.2023
On Tue, 20 Jun 2023 14:12:25 + Jani Heikkinen via Development wrote: > Qt 6.5 status: > > - Branching from '6.5' to '6.5.2' done > > - Qt 6.5.2 content is not frozen yet. The target is to freeze the Qt > 6.5.2 content later this week > > - The target is to release Qt 6.5.2 Wed 28th June What has hapenned to the 6.5.2 release? It's already 3rd July but there's no release, no task in Jira and no changes on the Qt 6.5 Release page on the wiki. 6.5.2 release is important as it fixes crashes with gesture management on X11 and Wayland and for X11 it (hopefully) should be first good release in Qt 6 series as X11 had scrolling problems all the Qt 6 lifetime and the release fixing it crashes on gestures. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Enorcing QT_SKIP_AUTO_[QML_]PLUGIN_INCLUSION
> On 3. Jul 2023, at 15:29, Lisandro Damián Nicanor Pérez Meyer > wrote: > > Hi! > > El lunes, 3 de julio de 2023 05:26:11 -03 Alexandru Croitor escribió: >>> On 30. Jun 2023, at 20:04, Lisandro Damián Nicanor Pérez Meyer >>> wrote: > [snip] >>> I recently noted the CMake variables QT_SKIP_AUTO_PLUGIN_INCLUSION and >>> QT_SKIP_AUTO_QML_PLUGIN_INCLUSION, which default to undefined. >>> >>> If I understand correctly the CMake file for searching for plugins are >>> there because: >>> >>> - One needs to find them when doing a static build in order to add them to >>> the final static object. >>> - One might use it to find the plugins and copy them when bundling >>> applications. >> >> That's right. >> >> For static plugins, the loading of plugin Config files and the availability >> of the cmake targets is needed for final linking purposes and also at >> configure time for running qmlimportscanner, and other qml tooling. >> For shared plugins, the targets are needed for deployment / bundling >> purposes (so runtime deps). >> >> One particular case which I'm not sure if it's used right now, but was >> brought up in various (private) discussions, is creating static qt plugins >> in a shared qt build. >> In a more recent discussion, it was about providing a static plugin >> containing just image assets. > > Perfect, so my understanding was more or less correct. So far none of the > above are use cases expected for a distro build. > >> Depending on what the plugin is linked to in the end, for example a qt tool >> in another repo, the plugin target would need to exist at build time, and >> thus the config files loaded. >> In this case, even a distro would have to load the file. > > And that would be a runtime dependency the tool has on the plugin, which is > just OK. If done properly that plugin will be installed due to packaging > dependencies. > I don't think that's a runtime dependency, it's a build time dependency, hence the Config files need to be loaded. To summarize the hypothetical case: qtbase is shared Qt build, so libQt6Gui.so, etc qtbase/src/plugins/icons/libqicons.a is a static qt plugin, even though Qt is a shared build. It belongs to the Gui module. qttools/src/tools/designer is an app. It needs to link to libqicons.a at build time. The qttools/src/tools/designer/CMakeLists.txt will refer to it via a CMake Target name e.g Qt6::QIconsPlugin, hence the Qt6IconsPluginConfig.cmake package needs to be found and loaded. That would usually be done automatically via the find_package(Qt6 COMPONENTS Gui) call because the default is to load all plugin config files. I suppose if the automatic loading is disabled, we can be explicit and add a find_package(Qt6 COMPONENTS IconsPlugin) in qttools/src/tools/designer/CMakeLists.txt and it would still work in your distro case. So TLDR, should be safe for your to disable the automatic loading of plugins during a shared Qt distro build atm. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Enorcing QT_SKIP_AUTO_[QML_]PLUGIN_INCLUSION
Hi! El lunes, 3 de julio de 2023 05:26:11 -03 Alexandru Croitor escribió: > > On 30. Jun 2023, at 20:04, Lisandro Damián Nicanor Pérez Meyer > > wrote: [snip] > > I recently noted the CMake variables QT_SKIP_AUTO_PLUGIN_INCLUSION and > > QT_SKIP_AUTO_QML_PLUGIN_INCLUSION, which default to undefined. > > > > If I understand correctly the CMake file for searching for plugins are > > there because: > > > > - One needs to find them when doing a static build in order to add them to > > the final static object. > > - One might use it to find the plugins and copy them when bundling > > applications. > > That's right. > > For static plugins, the loading of plugin Config files and the availability > of the cmake targets is needed for final linking purposes and also at > configure time for running qmlimportscanner, and other qml tooling. > For shared plugins, the targets are needed for deployment / bundling purposes > (so runtime deps). > > One particular case which I'm not sure if it's used right now, but was > brought up in various (private) discussions, is creating static qt plugins in > a shared qt build. > In a more recent discussion, it was about providing a static plugin > containing just image assets. Perfect, so my understanding was more or less correct. So far none of the above are use cases expected for a distro build. > Depending on what the plugin is linked to in the end, for example a qt tool > in another repo, the plugin target would need to exist at build time, and > thus the config files loaded. > In this case, even a distro would have to load the file. And that would be a runtime dependency the tool has on the plugin, which is just OK. If done properly that plugin will be installed due to packaging dependencies. > And there's no infrastructure yet to split loading static / shared plugin > Config files. Nor I think it will be needed, at least in the current status quo. > > Turns out that both the above use cases make no sense in Qt distro builds > > like Debian, **especially** when compiling (in other words, they are not > > build time dependencies, just run time dependencies). > > > > So I would __love__ to make those two variables enforced by qtbase itself. > > Granted, I could just patch out the required files in qtbase/cmake/ and > > check if the variable is defined. If it is, use it, else switch it to ON. > > But before going that route I would love to see if there is a more elegant, > > upstream-provided or upstream-guided way of doing it, like "send us a patch > > to do exactly that an we will take it". In this case please how I should > > achieve that, taking into account that I want this to be an opt-out, not an > > opt-in as currently is. > > In the context of distros, while it might not make sense to load the plugin > config files during a shared library qt build (aside from the more involved > use case above), those are still needed for end user-projects. But only at runtime, not build time (with the direct-dependency exception I mentioned above, but again, that's expected and handled). Yes, there _might_ be some project that requires finding the plugin... if there is one they can easily switch the variable on on that specific case. But on a distro they will still need to add the package with the required plugin(s) as a build dependency, and normally that's just enough. As another data point: we in Debian/Ubuntu have been removing plugins' CMake files for Qt 5 without a single issue neither for Qt nor all the rest of the huge set of applications/libraries using it. > So we can't skip including the files by default, the decision whether to load > the files depends on the intent / where the config files need to be used. > > A possible approach could be to detect if we are doing a qt build, in which > case QT_SKIP_AUTO_PLUGIN_INCLUSION would be considered TRUE. > Because find_package calls are done very early in every cml.txt, we usually > detect that it's done for a qt build by checking for the existence of > QT_REPO_MODULE_VERSION in .cmake.conf files that are included before the > find_package. > > Also, because i don't feel safe doing this for all qt builds (there might be > other reasons the qt build might want to know about plugin targets in the > future, outside the context of distro builds), i would protect such logic > behind a new option, something like QT_BUILDING_DISTRO. > > But at that point if distros have to set that, it's the same as setting > QT_SKIP_AUTO_PLUGIN_INCLUSION to TRUE themselves. > > And the only gain would be centralising distro-specific behaviors by keeping > such logic behind a QT_BUILDING_DISTRO check directly in qt code. > > Not sure if this is all worth it. No worries at all, I can always patch qtbase/cmake/QtPlugins.cmake.in and qtbase/cmake/QtPostProcessHelpers.cmake to invert the default state on our builds. That will really help us **a lot** because: - Neither Qt nor anything
[Development] Expanding Unity Build on CI for Qt Base
Hi, We are enabling the Unity Build for Qt Base on dev branch for a few more platforms: Windows 10 LLVM, Windows 11 LLVM, and macOS 12 x86_64, macOS 13 arm64 (for comparing the speed up between platforms.) While we are monitoring and experimenting with the build on CI, we may enable/disable the unity build on different platforms when necessary. Best, Amir. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Enorcing QT_SKIP_AUTO_[QML_]PLUGIN_INCLUSION
> On 30. Jun 2023, at 20:04, Lisandro Damián Nicanor Pérez Meyer > wrote: > > Hi! Hi > > I recently noted the CMake variables QT_SKIP_AUTO_PLUGIN_INCLUSION and > QT_SKIP_AUTO_QML_PLUGIN_INCLUSION, which default to undefined. > > If I understand correctly the CMake file for searching for plugins are there > because: > > - One needs to find them when doing a static build in order to add them to > the final static object. > - One might use it to find the plugins and copy them when bundling > applications. That's right. For static plugins, the loading of plugin Config files and the availability of the cmake targets is needed for final linking purposes and also at configure time for running qmlimportscanner, and other qml tooling. For shared plugins, the targets are needed for deployment / bundling purposes (so runtime deps). One particular case which I'm not sure if it's used right now, but was brought up in various (private) discussions, is creating static qt plugins in a shared qt build. In a more recent discussion, it was about providing a static plugin containing just image assets. Depending on what the plugin is linked to in the end, for example a qt tool in another repo, the plugin target would need to exist at build time, and thus the config files loaded. In this case, even a distro would have to load the file. And there's no infrastructure yet to split loading static / shared plugin Config files. > > Turns out that both the above use cases make no sense in Qt distro builds > like Debian, **especially** when compiling (in other words, they are not > build time dependencies, just run time dependencies). > > So I would __love__ to make those two variables enforced by qtbase itself. > Granted, I could just patch out the required files in qtbase/cmake/ and check > if the variable is defined. If it is, use it, else switch it to ON. But > before going that route I would love to see if there is a more elegant, > upstream-provided or upstream-guided way of doing it, like "send us a patch > to do exactly that an we will take it". In this case please how I should > achieve that, taking into account that I want this to be an opt-out, not an > opt-in as currently is. In the context of distros, while it might not make sense to load the plugin config files during a shared library qt build (aside from the more involved use case above), those are still needed for end user-projects. So we can't skip including the files by default, the decision whether to load the files depends on the intent / where the config files need to be used. A possible approach could be to detect if we are doing a qt build, in which case QT_SKIP_AUTO_PLUGIN_INCLUSION would be considered TRUE. Because find_package calls are done very early in every cml.txt, we usually detect that it's done for a qt build by checking for the existence of QT_REPO_MODULE_VERSION in .cmake.conf files that are included before the find_package. Also, because i don't feel safe doing this for all qt builds (there might be other reasons the qt build might want to know about plugin targets in the future, outside the context of distro builds), i would protect such logic behind a new option, something like QT_BUILDING_DISTRO. But at that point if distros have to set that, it's the same as setting QT_SKIP_AUTO_PLUGIN_INCLUSION to TRUE themselves. And the only gain would be centralising distro-specific behaviors by keeping such logic behind a QT_BUILDING_DISTRO check directly in qt code. Not sure if this is all worth it. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Compile error on MSVC: '/RTC1' and '/O2' command-line options are incompatible
Hi, this is https://bugreports.qt.io/browse/QTBUG-114925 . Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
