[Development] Summary of renaming changes

[Knoll Lars]

Hi,

looks like there's quite some discussion about Thiago's proposal. Let's see if we can get at least agreement on most of the changes and then focus on the parts that are controversial.

Going through the list below, most of the changes will not affect anybody in a big way. 


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

> After all of my patches are integrated, here are the changes that will happen:
> 
> - bin:
> The following tools have been renamed:
> 	qmake	-> qmake5

This one is visible to the developer.

> 	moc		-> moc5
> 	uic		-> uic5
> 	rcc		-> rcc5
> 	qdbusxml2cpp -> qdbusxml2cpp5
> 	qdbuscpp2xml -> qdbuscpp2xml5

Do we need to rename the dbus tools? They are compatible afaik.

But the name changes should be mostly invisible to developers as the tools are being called by the build system.

> 	lconvert	-> lconvert5
> 	lrelease	-> lrelease5
> 	lupdate	-> lupdate5

These tools are in-between, as they IMO get called both by build systems as well as by developers directly. But if they are not compatible with Qt 4, we can't really have the same name unfortunately.

> 	xmlpatterns -> xmlpatterns5
> 	xmlpatternsvalidator -> xmlpatternsvalidator5

The xmlpatterns tools don't need renaming IMO. Nothing has changed there, and I don't think they will.
> 
> 	qmlviewer -> qml1viewer
> 	[qml1plugindump had already been renamed]
> 
> 	qmlscene	-> qml2scene
> 	qmlplugindump -> qml2plugindump
> 	qmlbundle -> qml2bundle
> 	qmlmin -> qml2min
> 	qmlprofiler -> qml2profiler
> 	qmltestrunner -> qml2testrunner

Feels weird/wrong that we use qml1 and qml2, since we just renamed the QML 1/Quick 1module to QtDeclarative, and are trying to avoid the 2 for marketing as well.

Maybe use declarativeviewer and qmlscene instead?

> 
> The following tools require more information:
> 	qdoc: not renamed because the Qt 4 version was called "qdoc3"
> 	qhelpgenerator, qcollectiongenerator, qhelpconverter: they apparently 
> 	keep backwards compatibility, so they should replace the Qt 4 versions
> 	qglinfo: new tool from qt3d

These should be ok as is.
> 
> The following are user applications and they have not and will not be renamed:
> 	qdbus
> 	qdbusviewer
> 	assistant
> 	designer
> 	linguist
> 	creator
> 	pixeltool
> 
> - lib:
> All libraries are now called libQt5Name.so.5 on Unix systems, 
> libQt5Name(_debug).5.dylib on Mac, Qt5Name(d).dll on Windows. This also 
> applies to the qmake .prl files, the libtool .la files and the pkg-config .pc 
> files. The cmake files had already had the "5".
> 
> EXCEPT in Mac Framework builds. Since the header search path takes the 
> framework's name, for source compatibility, the framework builds did not get 
> the "5" in the name.

Don't see a problem with this, as it's transparent to the app developer.

>  - include:
> No change.
> 
> - doc:
> On Windows builds and on -no-prefix-install builds, no change. Otherwise, the 
> default install path is now $prefix/share/qt5/doc.
> 
> Question: should it be $prefix/doc/qt5 to match autoconf's default?

The second option is less linux centric, but is not being used by distributions afaict. I think distributions use either
/usr/share/doc/qt5 or /usr/share/qt5/doc.
> 
> - mkspecs:
> On Windows builds, on -no-prefix-install builds, and on builds with -hostprefix, 
> no change. Otherwise, the default install path is now $prefix/lib/qt5/mkspecs.

Sounds ok.
> 
> - plugins:
> The default install path is now $prefix/lib/qt5/plugins on all systems.

Ok as well.
> 
> - imports:
> The default install path is now $prefix/lib/qt5/imports on all systems. It 
> applies to QML 1 and Qt Quick 1 only.
> 
> QML2 imports go to "qmldir", which defaults to $prefix/lib/qt5/qml on all 
> systems.

Both ok for me.

Most of the changes above only affect build system maintainers, or people doing packaging. So in the end the discussion seems to boil down to the problem of renaming qmake, the one build tool that's very visible to developers.

Unfortunately qmake is bound to the Qt version and not backwards compatible. So if we want to make it possible to co-install Qt 5 with Qt 4, we have very little choice but to rename it.

On the plus side, this should then also be the main change that's visible to developers, and I don't think it's going to be a huge problem. For those of us using in-tree builds (and Qt4/Qt5 builds in parallel), we could simply extend the qset shell script many people are using to also add an alias from qmake to qmake5 when calling qset with a Qt 5 based Qt.

Cheers,
Lars