[Development] Qt 5 file hierarchy

Knoll Lars Lars.Knoll at digia.com
Mon Sep 24 12:20:12 CEST 2012


Hi Thiago,

On Sep 21, 2012, at 6:01 PM, Thiago Macieira <thiago.macieira at intel.com> wrote:

> The Qt 5 file hierarchy upon installation should be:

can you maybe come put up some motivations here and what you're trying to achieve? Just stating that this is how the file hierarchy is supposed to be is a bit weird. Is this a proposal for something?

In general, I agree that we should have a defined layout, but I am a bit confused about some your statements below, because they are very Linux specific in some places, and they change some fundamentals as names of binaries (from moc to moc5) that have to my knowledge not even been discussed yet.

So before going into details: Is this supposed to be a proposal for Linux or all platforms?

> 
> bin/		- executables run by the user
> 		- unversioned applications, like assistant, linguist, qdbus,
> 		  qdbusviewer
> 		- versioned applications, like qmake[35], qdoc5, qmlviewer5, 
> 		 maybe moc5, uic5, rcc5
> doc/		- gone to share/qt5/doc
> examples/ - gone to share/qt5/examples

All paths so far are Linux specific. I don't think they'd look that way on Mac or Windows.

> include/	- versioned include dirs:
> 	QtCore5 or QtCore-5 or QtCore.5 or Qt5Core/
> 	[…]

Doesn't work. On Linux it has to be include/qt5/QtCore. 

> 	Qt/ 	- gone, forever, no replacement

Ok for this one

> imports/	- horribly flawed design, see below
> lib/		- arch-specific files (also lib<qual> or lib/<arch>/)
> 	./		 - versioned libraries (.a, .so, .la, .prl)
> 	pkgconfig/ - versioned .pc files
> 	qt5/ 		 - arch-specific support files:
> 		bin/ or libexec/
> 		 - executables not run by the user, like syncqt, lrelease, lupdate
> 		imports/
> 		 - QtDeclarative imports
> 		qml2/
> 		 - QML2 (including QtQuick2) arch-specific imports

We already had a solution here (discussed that with Brisbane some months ago). QML2 is the default, so it goes into imports/. For QML1 we have a Quick1/ subfolder in imports.

> 		mkspecs/ ?
> share/	- arch-independent files
> 	qml2/	 - QML2 (including QtQuick2) arch-independent imports
> 	qt5/
> 		doc/
> 		examples/
> 		mkspecs/	?
> 
> 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. With Qt 5, it 
> becomes worse because Qt Quick 1 and 2 share the same directory.

They don't share the same directory really. See above. I am unsure I really want to even start differentiating arch dependent vs independent stuff here. Let's just declare it all arch dependent and simplify our lives for now.
> 
> 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.

Yes, putting it in lib/ on linux sounds reasonable.
> 
> 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.
> 
> As for mkspecs, I believe they should be in share, since they are technically-
> speaking arch-independent.

Cheers,
Lars




More information about the Development mailing list