On 27 Jul 2026, at 10:46, Volker Hilsheimer via Development <[email protected]> wrote:
On 26 Jul 2026, at 20:09, Thiago Macieira <[email protected]> wrote: In favour of QLibraryInfo::paths() https://codereview.qt-project.org/c/qt/qtbase/+/744726 The correct thing to do is to deprecate, and force everyone who is using it to adjust to having more than one path. In a lot of cases, it's already used in a loop, so the fix is simple. In others, it's the right thing to do. And in the rest, it documents in the code that you're taking the first and ignoring the remainder, which is what path() does. But it produces a lot of warnings in examples and tests. Do we want this? https://codereview.qt-project.org/c/qt/qtbase/+/560001 introduced paths() with https://qt-project.atlassian.net/browse/QTBUG-124009 "Support a way to easily set import paths for QML engine & tooling” as the rationale. Beyond QmlImportPaths, are there any other practical uses for respecting multiple entries? Yes, see series of patches under this topic: https://codereview.qt-project.org/q/topic:%22qlibraryinfo%22 tl;dr, plugins and other artifacts covered by QLibraryInfo might live both in the installed Qt and the app bundle on Apple platforms during development. And when deployed (into a single app bundle) there might be several paths inside that bundle we want to look for plugins and other artifacts. QLibraryInfo was originally designed to provide information about the Qt libraries, and having e.g. multiple locations of the Qt library translations, binary, or libraries doesn’t seem useful; but I might be missing something. That was the original design, based on the premise that Qt lives in a prefix-installed system location. Today with reloactable Qt we’ve moved away from the original design, so it’s more of a “where should I look for things Qt needs”. Tor Arne
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
