[Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)

[Kevin Kofler]

Thiago Macieira wrote:
> Reasons:
> - "etc" = 37 different binaries

That's what scripts are for. (How do you think we do the renames in the 
Fedora packages?)

> - inserting the argv check for the warning, as you suggest, in each of
>   them is work we'd rather not have and also which can go subtly wrong due
>   to bad copy & pasting

if (!QString::fromLocal8Bit(argv[0]).endsWith("-qt5"))
No editing for the copied&pasted code needed then.

Alternatively, just deprecate the unsuffixed binaries in the documentation 
only, those users who don't read the documentation will notice when they're 
gone in Qt 6.

> - the current solution is much simpler

It is actually much more complicated. Qtchooser is a complex wrapper that 
can be configured in at least 3 different ways (config files, environment 
variable, command line) and does not even handle all setups correctly at 
this time (e.g. multilib), so it can only become even more complex. Renaming 
the binaries is a simple file rename.

> - it was agreed upon in 2011

Fedora never agreed to the solution that was implemented. It clearly does 
not fulfill our requirements. Never did, never will.

>> in Qt 5.5, document the former as
>> deprecated in favor of the latter, also deprecate qtchooser. Eventually
>> drop the unsuffixed versions in Qt 6.0, shipping only -qt6 ones. The
>> result would be that programs still using Qt up to 4 would be no worse
>> off than they are right now, programs using Qt 5 would be able to migrate
>> to the now officially supported suffixed binaries (and if they don't,
>> they would be no worse off than they are right now either), and for Qt 6
>> and later, the issue would be resolved once and for all, there would be
>> one standard binary name to invoke: the suffixed one.)
> 
> ...because scripts that used to work with Qt 4 and Qt 5 should not have to
> change "moc" to "moc-qt6". We're trying to retain compatibility. Renaming
> tools does not read "compatibility".

Keeping tool invocation compatibility for a new major version of a library, 
which will definitely not be 100% source-compatible anyway (at the very 
least, deprecated functions will be dropped), strikes me as a "feature" of 
very limited usefulness.

Programs will likely need some amount of adaptation to Qt 6 anyway (they 
typically did for Qt 5) and so changing a hardcoded moc-qt5 (which they 
should already be using rather than moc at this point – if they're still 
using deprecated stuff, they'll need to get rid of that before porting to
Qt 6, this also goes for the code anyway) to trying both moc-qt6 and moc-qt5 
is going to be the least of the developer's worries.

        Kevin Kofler