[Development] Qt 5 file hierarchy

[Koehne Kai]

> -----Original Message-----
> From: development-bounces+kai.koehne=digia.com at qt-project.org
> [mailto:development-bounces+kai.koehne=digia.com at qt-project.org] On
> Behalf Of Thiago Macieira
> Sent: Friday, September 21, 2012 6:01 PM
> To: development at qt-project.org
> Subject: [Development] Qt 5 file hierarchy
> 
> [...]
> 
> Note on imports: the design is flawed. It was flawed in Qt 4 and it's worse
> now on Qt 5. For Qt 4, the flaw was that it did not differentiate QML
> imports that were arch-independent from the ones that required plugins.

Note that didn't have any .qml files defining libraries in stock Qt 4.x: All the plugins are libraries here. Now for Qt 5 there are indeed some .qml files installed in the directory (I counted 42) ... I see that it would be nice to have them in an arch-independent directory, but on the other side it's IMO not a real world problem if they're duplicated between a lib32 and lib64 directory.

> With Qt 5, it becomes worse because Qt Quick 1 and 2 share the same
> directory.

That's not completely true. The QtQuick1 library adds a custom import directory "$$QT_IMPORT_DIR/QtQuick1" which is always searched first. That's why we can have a QtQuick1 and QtQuick2 version of e.g. Qt.labs.folderlistmodel . (Not that I find this solution particularly elegant...)

> Instead, I recommend we immediately change QML2 to the system that Perl
> uses:
> put the arch-specific files inside the lib hierarchy, for which distributions
> have already solved the multiarch problem, but put arch-independent files in
> the share hierarchy.
> 
> In addition, the loader should be clever to merge similar names from the
> two different paths. That is, imagine a .qml file in share/qml2 that requires
> a
> plugin: if the loader is a 32-bit application, it would search for the plugin in
> lib/qt5/qml2, but if it's a 64-bit application it would search in
> lib64/qt5/qml2.
>
> Additionally, if we're still using QML2 by the Qt 6 release, the plugins could
> be made available in lib/qt6/qml2.

I think your proposal is sound, but I also don't see an immediate need to fix the imports for 5.0.

Regards

Kai