If I've forgotten anything, please add. As far as I can tell, here are the pending decisions, in increasing order of severity:
1) QML environment variables The variable for import paths has been versioned from QML_IMPORT_PATH to QML2_IMPORT_PATH. But I have not changed any of the other variables. We need a decision from the team familiar with the engines and the meanings of those variables to know which ones should be versioned too. They need to be versioned if having a value set in it applies to one QML engine but has ill-effects for the other. 2) QML tool names Kai raised the point that many of the QML 2 tools work for QML 1 too and maybe even for Qt 4's QML 1. We need confirmation on that as well as the willingness to keep them that way for one or two years at least. For the tools that work on both QML engines, we can drop the version number from their names. 3) library versioning (i.e., adding "5" to the library name) I'd like to see a decision here, one way or the other. I've posted my arguments in favour more than once and I know there are people who disagree. So let's hear from them why they disagree so we can see if there's a consensus[*]. I'll similarly post the arguments in favour and I'd appreciate if other people who agree did the same. 4) new installation paths (besides the bin directory) The latest patch I've provided creates a grouping of all arch-dependent files in ARCHDATADIR, with arch-independent files in DATADIR. That change, by itself, is innocuous since it doesn't produce any difference in installation. The decision we need is on the defaults for those two directories. My proposal is to have ARCHDATADIR=LIBDIR/qt5 and DATADIR=PREFIX/share/qt5 on Unix build that require make install *only*. Again, there are arguments for and against, so let's hear them. 5) executable split between end-user applications and indirect tooling The most controversial proposal so far is to split the binaries into two groups: one that gets installed to PREFIX/bin, containing the executables for applications run directly by the user and which retain backwards compatibility of purpose, and one that gets installed to ARCHDATADIR/bin that contains the tools that users generally do not run directly and which are specific to a particular build of Qt. Please note that, in the current implementation, like in #4 above, most people on this list will not see a change, as it applies to Unix builds that require make install *only*. This proposal has met with vehement opposition and I'd like to hear why. As a follow-up to this one, if we do split the executables, we need to decide which ones are applications and which ones are tooling. And among the latter, which ones need to be wrapped. Finally, I am not listing the separation of paths for QML 1 and 2, since I have not heard opposition to that fact. If I'm wrong, do speak up. [*] consensus does not mean unanimity -- 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