[Development] New proposal for the tool naming

[Konstantin Ritt]

>>> Solution:
>>>
>>> qmake renamed to qmake5 and lives with the other binaries in <libexec>/bin
>>> Create /usr/bin/qmake5 as a symlink to <libexec>/bin/qmake5 for Linux
>>> distro builds - triggered by some set of configure flags, NOT default
>>> behaviour for a source build
>>
>> You definitely don't want support multiarch configurations out-of-the-box :)
>> Well, yeah, switching with `sudo ln -svf /usr/lib/qt5/libexec/qmake5
>> /usr/bin/qmake5` is a way more handy than with `qmake -set-qt 5.0-x86`
>> (or even with `qmake -set-qt 5x86` if you created a symlink to the
>> 5.0-x86's config file).
>> And yeah, switching the system-default Qt for all users just to build
>> some crappyhelloworldexample .pro is a shiny new great idea :)
>
> "qmake -set…" would/should/must certainly set a *user* specific default. (There'd need to be other mechanisms for distributors and admins to set the system wide default.)

if we're talking about the new qmake wrapper, then yes, certainly.
however, the system wide default Qt version could be set by the
distributor easily with that qmake wrapper as well by simply replacing
the  default Qt version's config file somewhere at /etc/qmake (?) -
they could even have some "default" symlink there that would point to
the real config file of choice. so, if we're on multilib, thenthe
distributor would point /etc/qmake/default to, say,
qt5-unknown-linux-x86_64.  such an ability makes the distributor's
life easier whilst the system wide default version could be managed by
the "alternatives" tools I know.

on the other hand, having a /usr/bin/qmake5 symlink doesn't solve any
issues on multilib - we still need /usr/bin/qmake5-x86 in this case.

Konstantin


2012/10/24 Ziller Eike <Eike.Ziller at digia.com>:
>
> On 24 Oct 2012, at 08:04, Konstantin Ritt <ritt.ks at gmail.com>
>  wrote:
>
>>> Solution:
>>>
>>> qmake renamed to qmake5 and lives with the other binaries in <libexec>/bin
>>> Create /usr/bin/qmake5 as a symlink to <libexec>/bin/qmake5 for Linux
>>> distro builds - triggered by some set of configure flags, NOT default
>>> behaviour for a source build
>>
>> You definitely don't want support multiarch configurations out-of-the-box :)
>> Well, yeah, switching with `sudo ln -svf /usr/lib/qt5/libexec/qmake5
>> /usr/bin/qmake5` is a way more handy than with `qmake -set-qt 5.0-x86`
>> (or even with `qmake -set-qt 5x86` if you created a symlink to the
>> 5.0-x86's config file).
>> And yeah, switching the system-default Qt for all users just to build
>> some crappyhelloworldexample .pro is a shiny new great idea :)
>
> "qmake -set…" would/should/must certainly set a *user* specific default. (There'd need to be other mechanisms for distributors and admins to set the system wide default.)
>
>> Konstantin
>>
>>
>> 2012/10/24 Lincoln Ramsay <a1291762 at gmail.com>:
>>> On 24/10/12 04:33, Thiago Macieira wrote:
>>>> I think we are keeping it simple. The current proposal is the simplest
>>>> that still works. If you can come up with something even simpler, I'll
>>>> gladly accept it.
>>>>>> If the option is required in one platform and does not cause anything but
>>>>>> a minor inconvenience on others, why not document it?
>>>>> So then will Qmake on Windows/Mac complain about the "-qt5" argument? Or
>>>>> simply drop it?
>>>> Drop it.
>>>
>>> I know I complained about renaming qmake but... it would be simpler to
>>> rename qmake to qmake5 than to have a 'special' qmake that may or may
>>> not be the qmake that's first in your PATH and that may or may not do
>>> something with a -qtx switch.
>>>
>>> So I'm going to remove my +1 for the 'special' qmake and instead suggest
>>> a much simpler solution. This is just for 'qmake' though, everything
>>> else... same as it was before.
>>>
>>> Solution:
>>>
>>> qmake renamed to qmake5 and lives with the other binaries in <libexec>/bin
>>> Create /usr/bin/qmake5 as a symlink to <libexec>/bin/qmake5 for Linux
>>> distro builds - triggered by some set of configure flags, NOT default
>>> behaviour for a source build
>>>
>>> Optional:
>>>
>>> Create <libexec>/bin/qmake as a symlink to qmake5 (for Windows... a .bat
>>> or .cmd may work, else a copy).
>>>
>>> The "officially supported" way to build thus becomes "qmake5" and it is
>>> guaranteed to work no matter what platform you're on or how you've set
>>> your PATH. Yes, we have to update all the documentation.
>>>
>>> The optional symlink is for complainers like me, so we can continue to
>>> run qmake - but only if we set PATH correctly first. It'll also help
>>> with old instructions, scripts, etc. that would break if we just renamed
>>> qmake ;)
>>>
>>> --
>>> Link
>>>
>>> _______________________________________________
>>> Development mailing list
>>> Development at qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/development
>> _______________________________________________
>> 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
>