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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development