[Development] QLibraryInfo::path(): to deprecate or not to deprecate?

[Fabian Kosmale]

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

--
Fabian Kosmale
Manager

The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin
fabian.kosmale at qt.io
+49 1638686070
http://qt.io<http://qt.io/>

Geschäftsführer: Mika Pälsi, Juha Varelius, Juha Puputti
Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
--

Confidential
________________________________
Von: Development <development-bounces at qt-project.org> im Auftrag von Tor Arne Vestbø via Development <development at qt-project.org>
Gesendet: Montag, 27. Juli 2026 13:13
An: Volker Hilsheimer <volker.hilsheimer at qt.io>
Cc: Macieira, Thiago <thiago.macieira at intel.com>; development at qt-project.org <development at qt-project.org>
Betreff: Re: [Development] QLibraryInfo::path(): to deprecate or not to deprecate?



On 27 Jul 2026, at 10:46, Volker Hilsheimer via Development <development at qt-project.org> wrote:

On 26 Jul 2026, at 20:09, Thiago Macieira <thiago.macieira at intel.com> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260727/1fac59f8/attachment.htm>