[Development] Pending decisions on co-installation

[Thiago Macieira]

On quinta-feira, 1 de novembro de 2012 10.01.11, Chris Adams wrote:
> Regarding QML_IMPORT_PATH, I discussed this yesterday and this morning with
> Martin Jones and Andrew den Exter, and a couple of things deserve
> mentioning:
> 1) through the versioning of imports (ie, the path lookup with major/minor
> version appended to module name) a client can create a QML1
> (QDeclarativeExtensionPlugin) module plugin and install it into, say,
> "$QML_IMPORT_PATH/com/examplecompany/examplemodule1/" and then create a
> QML2 (QQmlExtensionPlugin) module plugin and install it into
> "$QML_IMPORT_PATH/com/examplecompany/examplemodule2/", and this will work
> fine.
> 
> That is, the QML_IMPORT_PATH need not be different (or set differently)
> between applications using QML1 and QML2, so long as they import the
> modules of the correct version (ie, for the version of QML against which
> their application is written).

That assumes that there is a different module name or version number, which 
isn't always the case. Qt Quick did decide to break source compatibility by 
requiring "import QtQuick 2", but the same does not follow for other imports.

Note that there already was a separate import path for Qt Quick 1 by appending 
"QtQuick1" to the paths found in QML_IMPORT_PATH. And it is used by some code 
that we install ourselves, like Qt.labs.folderlistmodel.

$ cat imports/Qt/labs/folderlistmodel/qmldir 
plugin qmlfolderlistmodelplugin

$ cat qml/Qt/labs/folderlistmodel/qmldir    
module Qt.labs.folderlistmodel
plugin qmlfolderlistmodelplugin
typeinfo plugins.qmltypes


> So, I'm not sure that QML_IMPORT_PATH needs to be versioned, so long as
> QML's imports versioning system works as expected in future versions.
> I'm not sure that we need to have a qt5/imports dir for QML1 plugins and a
> separate qt5/qml dir for QML2 plugins, since coexisting qq1/qq2 plugins
> worked previously according to versioning, with the same import path.

No, they didn't. They already had different import paths before I started doing 
anything. All I did was change the paths searched and the environment 
variables that supply the paths.

> A
> problem might occur if you set QML_IMPORT_PATH to point to a qt4 (QML1)
> import path, and then run a qt5 QML1 application - it'll be trying to load
> QML1 plugins built against qt4, which will fail.

Indeed, but hopefully the Qt plugin system will simply refuse to load the 
plugins, avoiding a crash. The QML plugins *are* Qt plugins, loaded via 
QPluginLoader, aren't they?

This is the same situation with QT_PLUGIN_PATH, which is unversioned. However, 
the plugin magic is incompatible between Qt 4 and 5, so we can keep the same 
environment variable, which contains both sets of plugin paths. Qt 4 will not 
load Qt 5 plugins and Qt 5 will not load Qt 4 plugins.

> Anyway, the long and short of it is -- these variables / configure options
> are all developer-facing, so to be honest, we don't think it's a huge issue
> to change them if we want to, or leave them (and document the differences
> if required) if that is simpler or less confusing.

All of them except for QML_IMPORT_PATH. That can be expected to be set on a 
production system, like some other variables that modify Qt's behaviour post-
installation:

	QT_PLUGIN_PATH
	QT_QPA_PLATFORM_PLUGIN_PATH
	QT_QPA_PLATFORM
	QT_MESSAGE_PATTERN

For example, my default shell environment has:

$ echo $QT_PLUGIN_PATH 
/home/thiago/obj/qt/qt-4.8-
release/plugins:/home/thiago/kde/lib/kde4/plugins:/usr/lib64/qt4/plugins:/home/thiago/.kde/lib/kde4/plugins/:/home/thiago/kde/lib/kde4/plugins/:/usr/lib/kde4/plugins/:/home/thiago/kde/lib/plugins/:/usr/lib64/kde4/plugins

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121031/07ed60b1/attachment.sig>