[Development] Qt 5 file hierarchy

Knoll Lars Lars.Knoll at digia.com
Mon Sep 24 14:38:51 CEST 2012


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

> On segunda-feira, 24 de setembro de 2012 11.44.51, Knoll Lars wrote:
>>>> 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.
> 
> The Qt 4 plugins live in the Qt4 prefix. Existing practice is that it's 
> /usr/lib$SUFFIX/qt4/{plugins,imports}. So we don't clash with those.
> 
> Technically speaking, since we're changing to qt5 anyway, we could change the 
> default to be QtQuick2. But that means code using QtDeclarative and Qt Quick 1 
> must install to a different directory under imports, which is more change.

The imports from the qtquick1 module already do that.
> 
> My proposal is to leave QtQuick 1 unchanged and establish a new hierarchy for 
> Qt Quick 2. Also note that the "share" dir I proposed does not include the 
> "qt5" name.

That's scary… I wouldn't recommend that. People should explicitly test against Qt 4 and Qt 5 not get this implicitly.
> 
>>> 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.
> 
> True, we could add the platform-independent search paths in a later release. 
> Also note that the search functionality is is implemented in QStandardPaths. 
> It already has the necessary logic.

Let's leave this out of 5.0, to simplify things.

Cheers,
Lars

> 
>>> -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.
> 
> Me too.
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
>     Intel Sweden AB - Registration Number: 556189-6027
>     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development




More information about the Development mailing list