[Development] Pending decisions on co-installation

Knoll Lars Lars.Knoll at digia.com
Thu Nov 1 09:47:12 CET 2012


Hi,

after reading through the whole thread, here's my comments on the different parts:

On Oct 30, 2012, at 9:47 PM, Thiago Macieira <thiago.macieira at intel.com> wrote:

> 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.

Let's separate the import paths. As Chris has pointed out, we do not need changes to the other environment variables, as they are purely developer facing and usually there only for debugging purposes.
> 
> 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.

I think most things are now settled, the main remaining ones are the qmlviewer/qmlscene names. As Chris said, they do somewhat different things. qmlviewer for QML1 actually adds a 'runtime' object into the QML environment and does some other magic. qmlscene is just instantiating a QQuickView and then executing the qml. So I'd go for qml1viewer and qml2scene, but let's hear if Chris/Martin have any further comments.

Btw, we had a discussion here in Oslo that it would be great to at some point have a real qml runtime available. Probably simply called 'qml' as well. But let's keep that for a separate mail.

> 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.

After reading through it all, I'd say let's go with adding the '5' in there. It's slightly ugly, but most people will rarely have a need to see or use the library names directly. 

It shouldn't really make things more difficult for most of our users. People using qmake or cmake will never even notice. That leaves people with hand-written makefiles/vcproj files etc.

Here Windows developers will need to adjust anyway, as we already have the major version number encoded in the dll name. On Linux/Unix some adjustments will also be required due to the library splits, so people will need to touch some pieces there anyway. And on Mac with frameworks nothing changes.

So this seams reasonable, and allows for more easy co-installation in /usr/lib. As Thiago pointed out, modifying the link path with -L… is not a very stable solution as soon as 3rd party libs come into play. This is simply the safer solution IMO.

> 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.

Hmm… as far as I can see from the discussion, you only plan on using this for mkspecs. Is it then worth it? Also, mkspecs have the default/ symlink which is IMO not arch independent.
> 
> 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.

It seems to be very hard to get any further with this on the list, and I'm hearing good arguments from both sides.

I'd propose that we get this (and (4) if still needed) sorted out at the Contributor Day in Berlin in 10 days. Most people that have voiced strong opinions on the topic are coming to Berlin (or living there), and resolving this face to face is probably a lot easier then continuing to discuss on the list.

This also implies that this change won't be part of Beta 2.
> 
> 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.

I think that's agreed.

Cheers,
Lars




More information about the Development mailing list