[Development] Co-installation & executable naming rules

[Ziller Eike]

On 8 Oct 2012, at 14:58, Simon Hausmann <simon.hausmann at digia.com> wrote:

> On Friday, September 21, 2012 05:24:16 PM Thiago Macieira wrote:
>> On sexta-feira, 21 de setembro de 2012 16.47.11, Thiago Macieira wrote:
>>> Include the major version number (5) in all library base names, like on
>>> Windows, on all platforms. On Windows we already have QtCore5.dll and
>>> QtV85.dll, so I recommend having libQtCore5.so.5. For Mac, I'm not sure of
>>> the  naming scheme, but the recommendation applies.
>>> 
>>> This recommendation also applies to the static library archives
>>> (libQtCore5.a), qmake library files (libQtCore5.prl), libtool archives
>>> (libQtCore5.la) and pkgconfig files (QtCore5.pc). CMake files already have
>>> the  version number. but in a different place (Qt5Core).
>>> 
>>> I recommend harmonising the cmake names, either by changing them to
>>> QtCore5
>>> or  by changing the library naming to match the cmake files
>>> (libQt5Core.so,
>>> Qt5Core.pc, etc). Or one of the other alternatives at the bottom of this
>>> email.
>>> 
>>> PS: this recommendation does not apply to executables. See follow-up
>>> email.
>> 
>> For executables, the situation is similar. The difference is that
>> executables have three categories, not just two:
> 
> We just had a discussion in the Oslo office about this. We suggest to basically 
> follow your proposal, with an addon to hide some of the uglyness it brings 
> along.
> 
> Let me try to summarize very shortly. The base proposal would be to include 
> the major Qt version throughout the project:
> 
>    1) Prefix the libraries, i.e. libQt5Core, libQt5Gui, etc.
>    2) Prefix the pkg-config files (Qt5Core.pc, etc.)
>    3) Prefix the binaries (qt5designer, qt5moc, qt5make) (note that this is 
> referring to the binaries, not the user visible names or bundle names)
> 
> This allows for co-installation on all platforms (even on ones where there 
> exists no problem of co-installation :)
> 
> 
> Now this has some ugly implications, everyone will have to change the way they 
> develop with Qt 5. In this context we have another interesting artifact: 
> People who have been developing Qt for a long time as part of company efforts 
> such as Trolltech, Nokia or now Digia will know that by now pretty much every 
> developer has their own set of shell scripts to deal with multiple 
> simultaneously installed Qt versions. We've had a few attempts at 
> consolidating these efforts, with varying success (devtools / qset). Now one 
> thing we came up with in our local discussion here is that maybe it's time to 
> bring this idea forward and use it to solve the "uglyness" of co-installation 
> in production environments:
> 
> We could have a tool (let's call it just "qt") that makes choosing between 
> different versions/installations of Qt easier. The tool should read and write 
> the existing Qt Creator Qt version registry (so that everything is always in 
> sync). It could allow for forwarding calls to executables (qt --4 qmake -> 
> call qt4's qmake; qt --6 qmake -> call qt6's qmake, same for moc, uic, 
> designer, etc.).
> 
> It could also be a tool that's aware of defaults, so that just calling "qt 
> qmake" would call qmake from the currently selected Qt version. It could also 
> support changing your environment (if its front-end was a batch file and shell 
> script), so that you could write "qt --set 5" and further invocations of "qt 
> qmake" in the same shell/environment would automatically pick qt5's qmake.
> 
> If the tool used Qt Creator's registry of Qt versions, then it would also be 
> suitable for Qt developers who may have different versions of the same major 
> version installed on the same computer and want to often quickly change 
> between them within a terminal.

Not sure what you mean with how that tool would "use Qt Creator's registry".
I'd rather not have that tool change the registered Qt versions in Qt Creator. It would be better if one could register the "current default Qt" in Qt Creator, i.e. a Qt version that follows whatever is set with the tool. That way you can have the fixed Qt versions that we know, and if you want you can define a Qt version + Kit that follows whatever your terminal setting is. (Easiest for that would be if the "default qmake" would just be called "qmake" and point to whatever is currently set to be the default.)

> The Qt tool itself could be written using the internal Qt bootstrap library.
> 
> 
> What do you think?
> 
> Folks from the Oslo discussion: anything I missed?
> 
> 
> Simon
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B