> On 27 Jul 2026, at 13:21, Fabian Kosmale <[email protected]> wrote: >>> 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”. > > > Hi, > > besides the Apple use case Tor Arne listed, I believe we have seen similar > requirements for Harmony OS, and you also run into interesting issues with > NixOS if I recall correctly (though the latter is at least not officially > supported). > Qt itself should definitely not use the singular form; I'm not quite sure how > much usage the API sees in user applications. > > In any case, if we deprecate the singe item API, we should however provide > some more guidance than just "us paths". > > Fabian
Ok; it then seems reasonable for the next step to be a cleaning up of in-tree code, see what we can learn from that (if anything; tests can perhaps get away with s/path()/paths().first()?), and only deprecate once we have a clean source tree ourselves and a good porting guideline. Cheers, Volker -- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
