[Development] Qt 5 file hierarchy

[Knoll Lars]

On Sep 24, 2012, at 12:43 PM, Thiago Macieira <thiago.macieira at intel.com>
 wrote:

> On segunda-feira, 24 de setembro de 2012 10.20.12, Knoll Lars wrote:
>> 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.
> 
> The discussion is on the other thread on the why this is needed.

Yes, seen it afterwards. 
> 
>> So before going into details: Is this supposed to be a proposal for Linux or
>> all platforms?
> 
> It's needed for Linux, but the path of least resistance is to do it on all 
> platforms.

Not really. Mac has also it's conventions on how frameworks should look. If we follow Linux conventions on Linux we should just as well follow Mac conventions on the Mac.

> 
>>> 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.
> 
> Ok, fair enough. We do have configure options for those paths and every single 
> packager is using them already.
> 
>>> 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.
> 
> Yup, it was a mistake suggesting this.
> 
>>> 	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.
> 
> That's not acceptable. The QtQuick1 & libQtDeclarative.so.5 hierarchy must be 
> the default because that's what people are using now. QML2 plugins must be the 
> ones in a different path.

Actually we have Qt 4 and Qt 5. That's the bigger problem. C++ plugins for Quick1 are binary incompatible between Qt 4 and Qt 5. Within Qt5 the current approach works fine.
> 
> Are you also implicitly agreeing to move imports into lib (which all distros 
> already do anyway)?

Yes, imports living under lib/ is fine for me.
> 
>>> 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.
> 
> I think that goes against the purpose of QML. We've been suggesting to a lot 
> of people that they can write QML-based applications and solutions without 
> writing a single line of C++. I think we *want* to say that you can install 
> platform-independent solutions.
> 
> I don't mind if the maintainers in QtQuick1 and QtQuick2 decide they want to 
> declare QML to follow the same rules as native code. It's really their choice.

So far that's what we've been saying. My main concern currently is implementability. If we keep it all in one folder, we don't need to do additional development. Otherwise we need to duplicate lookups and search paths. Please also note that some QML modules could be mixed QML and C++.

In addition, we're currently doing some research here (more about that later and separately) on how to compile QML into byte code or even native code.
> 
>>> 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.
> 
> -importsdir is a nonstandard option. I recommend we move the imports dir into 
> $prefix/lib/qt5 by default. On all platforms.
> 
> Also note my proposal missed the plugins dir. I make the same recommendation: 
> move it into lib/qt5 by default.

I'm personally fine with both. It also simplifies configuration (removes two options that we'd need to support), but I'd like to hear if someone sees any problems with moving these two dirs.

Cheers,
Lars