Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

On Fri, 26 Feb 2021 at 10:24, Kai Köhne  wrote:
> > -Ursprüngliche Nachricht-
> > Von: Development  Im Auftrag von
> > Joerg Bornemann
> > Gesendet: Freitag, 26. Februar 2021 13:36
> > An: Elvis Stansvik 
> > Cc: Macieira, Thiago ; Qt development mailing
> > list 
> > Betreff: Re: [Development] Qt 6 co-installability with Qt 5
> >
> > On 2/24/21 8:54 AM, Elvis Stansvik wrote:
> >
> > > I guess it rules out installing to e.g. a FAT-formatted USB-stick, but
> > > I don't know if that's a thing. Could be considered an edge case and
> > > documented not to work.
> >
> > With https://codereview.qt-project.org/c/qt/qtbase/+/336652 a copy is made
> > if a hard-link cannot be created.
>
> Right, but that is at configure time, this doesn’t help with the online 
> installer.
>
> If we go down this route, we should arguably check in the online installer 
> whether the target folder is on an NTFS partition, and back out if not. One 
> more complication ... :/

Then just rename the binaries, update docs and everything goes smooth ;-)


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Joerg Bornemann]

On 2/26/21 2:23 PM, Kai Köhne wrote:


With https://codereview.qt-project.org/c/qt/qtbase/+/336652 a copy is made
if a hard-link cannot be created.


Right, but that is at configure time, this doesn’t help with the online 
installer.


To be pedantic, it's at cmake --install time. :-)


If we go down this route, we should arguably check in the online installer 
whether the target folder is on an NTFS partition, and back out if not. One 
more complication ... :/


Well my optimistic theory is:
- CI builds + installs the Qt module (for example qtbase) in a packaging 
config.
- CI creates a 7z archive and either 7za is clever and detects the hard 
link or just archives the binary twice.
- The installer extracts the archive on the user's machine. Either the 
archived hard links can be extracted or copies are made.



Cheers,

Joerg
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Kai Köhne]

> -Ursprüngliche Nachricht-
> Von: Development  Im Auftrag von
> Joerg Bornemann
> Gesendet: Freitag, 26. Februar 2021 13:36
> An: Elvis Stansvik 
> Cc: Macieira, Thiago ; Qt development mailing
> list 
> Betreff: Re: [Development] Qt 6 co-installability with Qt 5
> 
> On 2/24/21 8:54 AM, Elvis Stansvik wrote:
> 
> > I guess it rules out installing to e.g. a FAT-formatted USB-stick, but
> > I don't know if that's a thing. Could be considered an edge case and
> > documented not to work.
> 
> With https://codereview.qt-project.org/c/qt/qtbase/+/336652 a copy is made
> if a hard-link cannot be created.

Right, but that is at configure time, this doesn’t help with the online 
installer. 

If we go down this route, we should arguably check in the online installer 
whether the target folder is on an NTFS partition, and back out if not. One 
more complication ... :/

Regards

Kai

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Joerg Bornemann]

On 2/24/21 8:54 AM, Elvis Stansvik wrote:

I guess it rules out installing to e.g. a FAT-formatted USB-stick, but I 
don't know if that's a thing. Could be considered an edge case and 
documented not to work.


With https://codereview.qt-project.org/c/qt/qtbase/+/336652 a copy is 
made if a hard-link cannot be created.



Cheers,

Joerg
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Elvis Stansvik]

Den tis 23 feb. 2021 21:27Joerg Bornemann  skrev:

> On 2/23/21 8:52 PM, Thiago Macieira wrote:
> > On Tuesday, 23 February 2021 00:00:22 PST Joerg Bornemann wrote:
> >> On 2/20/21 2:44 AM, Thiago Macieira wrote:
> >>> Besides, doesn't Windows now have symlinks?
> >>
> >> For admin users only unless an admin user enables them for everyone.
> >> Hard-links are available though on NTFS.
> >
> > Can we use the hard-links then?
>
> CMake supports creating hard links with file(CREATE_LINK).
>
> "cmake --install" does not directly support creating hard links. One
> would probably have to use install(SCRIPT) with a script that runs
> file(CREATE_LINK).
>
> For the installer, 7zip supports storing hard links since 9.33.
>
> Without trying anything, it looks like using hard links could work.
>

I guess it rules out installing to e.g. a FAT-formatted USB-stick, but I
don't know if that's a thing. Could be considered an edge case and
documented not to work.

Elvis


>
> Cheers,
>
> Joerg
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Joerg Bornemann]

On 2/23/21 8:52 PM, Thiago Macieira wrote:

On Tuesday, 23 February 2021 00:00:22 PST Joerg Bornemann wrote:

On 2/20/21 2:44 AM, Thiago Macieira wrote:

Besides, doesn't Windows now have symlinks?


For admin users only unless an admin user enables them for everyone.
Hard-links are available though on NTFS.


Can we use the hard-links then?


CMake supports creating hard links with file(CREATE_LINK).

"cmake --install" does not directly support creating hard links. One 
would probably have to use install(SCRIPT) with a script that runs 
file(CREATE_LINK).


For the installer, 7zip supports storing hard links since 9.33.

Without trying anything, it looks like using hard links could work.


Cheers,

Joerg
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Thiago Macieira]

On Tuesday, 23 February 2021 00:00:22 PST Joerg Bornemann wrote:
> On 2/20/21 2:44 AM, Thiago Macieira wrote:
> > Besides, doesn't Windows now have symlinks?
> 
> For admin users only unless an admin user enables them for everyone.
> Hard-links are available though on NTFS.

Can we use the hard-links then?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Joerg Bornemann]

On 2/20/21 2:44 AM, Thiago Macieira wrote:


Besides, doesn't Windows now have symlinks?


For admin users only unless an admin user enables them for everyone.
Hard-links are available though on NTFS.


Cheers,

Joerg
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Thiago Macieira]

On Friday, 19 February 2021 01:40:21 PST Elvis Stansvik wrote:
> Yea that would work, but what about Windows that doesn't really have
> symlinks? Would you install copies of the executables under both names?

Or a simple stub that launches the other executable with the same arguments.

Besides, doesn't Windows now have symlinks?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Elvis Stansvik]

Den fre 19 feb. 2021 01:26Thiago Macieira  skrev:

> On Thursday, 18 February 2021 08:30:16 PST Elvis Stansvik wrote:
> > I think just suffix all the binaries (all of them) everywhere, and update
> > the docs everywhere. See how simple it would be. Yes it will cause some
> > breakage, but definitely worth it in my opinion.
>
> We don't even need to cause breakage. Just install both names and update
> the
> docs to the new names.
>

Yea that would work, but what about Windows that doesn't really have
symlinks? Would you install copies of the executables under both names?

With everywhere I meant including the SDK from TQtC.

Elvis


> On a source build, make the public bindir == private bindir. For
> system-wide
> builds, the distributor chooses to separate.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel DPG Cloud Engineering
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Thiago Macieira]

On Thursday, 18 February 2021 08:30:16 PST Elvis Stansvik wrote:
> I think just suffix all the binaries (all of them) everywhere, and update
> the docs everywhere. See how simple it would be. Yes it will cause some
> breakage, but definitely worth it in my opinion.

We don't even need to cause breakage. Just install both names and update the 
docs to the new names.

On a source build, make the public bindir == private bindir. For system-wide 
builds, the distributor chooses to separate.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Elvis Stansvik]

I think just suffix all the binaries (all of them) everywhere, and update
the docs everywhere. See how simple it would be. Yes it will cause some
breakage, but definitely worth it in my opinion.

Elvis

Den tors 18 feb. 2021 17:25Thiago Macieira 
skrev:

> On Thursday, 18 February 2021 01:56:55 PST Tor Arne Vestbø wrote:
> > > Make that "mac building" too, because it shall apply to Homebrew.
> >
> >
> > Sorry, no. If Homebrew renames binaries, that’s a Homebrew documentation
> > installation documentation issue. How Qt is built from source on macOS
> has
> > no relation to that.
>
> The point is that it applies to more than one platform, including mac.
> Therefore, it should be more visible than "linux-building".
>
> Also, Qt when built from sources should match the majority of build styles
> too.  Or put another way: what do we lose by having the common name that
> everyone shares in the default?
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel DPG Cloud Engineering
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Thiago Macieira]

On Thursday, 18 February 2021 01:56:55 PST Tor Arne Vestbø wrote:
> > Make that "mac building" too, because it shall apply to Homebrew.
> 
> 
> Sorry, no. If Homebrew renames binaries, that’s a Homebrew documentation
> installation documentation issue. How Qt is built from source on macOS has
> no relation to that.

The point is that it applies to more than one platform, including mac. 
Therefore, it should be more visible than "linux-building".

Also, Qt when built from sources should match the majority of build styles 
too.  Or put another way: what do we lose by having the common name that 
everyone shares in the default?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Tor Arne Vestbø]

> On 17 Feb 2021, at 23:39, Thiago Macieira  wrote:
> 
> On Wednesday, 17 February 2021 00:32:13 PST Joerg Bornemann wrote:
>> Yes, and that's all good, and with
>> https://codereview.qt-project.org/c/qt/qtbase/+/334054 we will have an
>> offical recommendation.
>> I will also add a documentation page in the vicinity of
>> https://doc.qt.io/qt-6/linux-building.html
> 
> Make that "mac building" too, because it shall apply to Homebrew.

Sorry, no. If Homebrew renames binaries, that’s a Homebrew documentation 
installation documentation issue. How Qt is built from source on macOS has no 
relation to that.

Tor Arne 
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Thiago Macieira]

On Wednesday, 17 February 2021 08:13:41 PST Kai Köhne wrote:
> Anyhow, now that we've been both venting our frustration a bit: As Joerg
> already pointed out, I'm completely fine with the patch he has prepared,
> and certainly do hope that distributions make use of it. I'm just
> disagreeing with the request that the Qt documentation need also state
> 'qmake6' everywhere, and that the Qt SDK (as provided by the online
> installer) needs to contain 'qmake6', too.

The documentation needs to reflect reality. If there are sufficient builds 
that do rename (and there will be), the documentation should mention. I think 
this is something we can agree on.

I won't opine on the SDK from TQtC. I don't use it as it isn't meant for 
developers of Qt. And since it can't be anonymously downloaded any more, I 
probably never will either. It's your choice whether to apply the naming the 
majority chooses.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Thiago Macieira]

On Wednesday, 17 February 2021 00:32:13 PST Joerg Bornemann wrote:
> Yes, and that's all good, and with
> https://codereview.qt-project.org/c/qt/qtbase/+/334054 we will have an
> offical recommendation.
> I will also add a documentation page in the vicinity of
> https://doc.qt.io/qt-6/linux-building.html

Make that "mac building" too, because it shall apply to Homebrew. Windows has 
no concept of global paths, so it doesn't matter there.

I also think the step should be automatic from the CMake build, instead of an 
optional extra. That will lead to confusion because people will forget and 
then send questions into forums and mailing lists.

> 
> The only thing we're still arguing about is how to call the tools in the
> documentation.

I think we should follow the majority, both in quantity and in volume.

All but one of the binary distributions will rename. That's all the Linux 
distributions, FreeBSD ports tree, Homebrew on Mac, and possibly Conan on 
Windows too.

Therefore, we do request that it be made obvious that it is called "qmake6" 
and "qtdiag6" almost everywhere.

The official build from qt.io, which is much less important these days because 
it can't be anonymously downloaded, can be the odd one out if it wants to. I 
suggest that you do apply the new name there too, but that's your choice. Just 
don't make your minority choice rule the user experience for the majority.

> To mention that the distro-provided qmake might be called qmake6 can
> (and should) also be done. But to change qmake to qmake6 everywhere in
> the docs is as consistent as not doing anything - as long as we don't
> rename the tools.

I agree with the arguments.

Therefore, I come to the conclusion the tools should be renamed.

> Renaming just the three tools you mentioned would be inconsistent.
> Renaming all tools is too late.

No, it isn't. We agreed that 6.1 would be an acceptable target for this 
massive change because we didn't want to risk 6.0, therefore it is acceptable. 
No one is currently using 6.0 because it's incomplete for many applications 
and because it is a dot-zero release.

Also note that the longer those modules go unmaintained, the bigger the chance 
people will simply begin porting away from Qt entirely. I've already been 
asked that question inside Intel: projects that were on the last LTS (5.12) 
are trying to figure out their futures.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Thiago Macieira]

On Wednesday, 17 February 2021 04:32:43 PST Lisandro Damián Nicanor Pérez 
Meyer wrote:
> > Obviously not with enough fervor to convince people and in the case of
> > Qt6 mch too late in the release process.
> 
> In fact the most difficult people to convince are within tqtc. And no, we
> have been asking for this change, specifically for qt6, since at very least
> 2019. And they where no small threads.

It was asked multiple times for Qt 5 and Qt 6 (there was no open governance 
for Qt 4, so there was no way to have the discussion then). For Qt 5, we 
thought we had a good solution with qtchooser, but it turns out that it isn't. 
The one for Qt 6 was raised early in the process, but no one acted. So it was 
raised again, before the release, and we agreed on what needed to be done, but 
it wouldn't gate the 6.0 release if it didn't get done.

It gates 6.1.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Ville Voutilainen]

On Tue, 16 Feb 2021 at 17:08, André Pönitz  wrote:
> I agree that update-alternatives is Just Wrong for something that
> should effectively be the user's decision (and not even a decision
> for all of the user's projects but something that needs to be done
> case-by-case).
>
> On the other hand I don't quite understand all the fuzz about the
> Correct Global Name. When I as a user am not happy with someone's
> decision on how to name a binary or if a distribution acts funnily or if
> I am too lazy to change my muscle memory I set up a shell alias to do
> what I want.

Well, that sort of thing works great as a local solution, but consider
reused scripts,
tools, etc. recipes, if you take one of those and run it in your
environment, will it do the
right thing, the expected thing? Will it do the expected thing if you
have both qt 5 and
qt 6 on your system? Will it do the expected thing if you have just
one of them? Will
it do the expected thing if you have just one, and then switch to the other?

Therein lies the reason for the fuzz and fuss about the correct global name.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Rex Dieter]

Sorry for the mis-threading (my replies to this list haven't been working
right recently), but...

As for thiago's proposal:
> 1) the binaries from Qt company must also perform this step
> 2) the documentation has to be updated to include the "6" at the end too

+1 (+million),

this proposal speaks truth, please, please standardize... Fedora
maintainers support this whole-heartedly.  Pretty sure RHEL maintainers I
collaborate with would agree as well.

Obviously, item 1 is the most important.  If there's anything to learn from
python as mentioned elsewhere, please do item 2 too, leaving no ambiguity
and making expectations clear in documentation is good thing.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Wed, 17 Feb 2021 at 13:13, Kai Köhne  wrote:
[snip]
> > In fact the most difficult people to convince are within tqtc. And no, we 
> > have been asking for this change, specifically for qt6,
> > since at very least 2019. And they where no small threads.
>
> That might have less to do with the fact we work for The Qt Company, but more 
> with the fact that a) you ask us to do the work, and b) to maintain it

For (a) I can feel some guilt, but sadly having to get the paycheck
has become more important nowadays :-/ For (b): the renaming, at very
least on Linux (although Homebrew really needs it too), no matter the
source of the binaries, is just the right thing to do.

> Anyhow, now that we've been both venting our frustration a bit: As Joerg 
> already pointed out, I'm completely fine with the patch he has prepared, and 
> certainly do hope that distributions make use of it. I'm just disagreeing 
> with the request that the Qt documentation need also state 'qmake6' 
> everywhere, and that the Qt SDK (as provided by the online installer) needs 
> to contain 'qmake6', too.

Well, it seems we will keep disagreeing for quite some time then :-)

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Kai Köhne]

> Von: Development  Im Auftrag von Lisandro 
> Damián Nicanor Pérez Meyer
> Gesendet: Mittwoch, 17. Februar 2021 13:33
> An: development@qt-project.org
> Betreff: Re: [Development] Qt 6 co-installability with Qt 5
>
> Hi!
> El mié., 17 feb. 2021 05:33, Joerg Bornemann <mailto:joerg.bornem...@qt.io> 
> escribió: 
>
> On 2/17/21 12:47 AM, Lisandro Damián Nicanor Pérez Meyer wrote:
>
>> Kai: we the maintainers have been asking for the right solution since 
> the Qt3 to Qt4 switch.
>
> Obviously not with enough fervor to convince people and in the case of 
> Qt6 mch too late in the release process.
>
> In fact the most difficult people to convince are within tqtc. And no, we 
> have been asking for this change, specifically for qt6, 
> since at very least 2019. And they where no small threads.

That might have less to do with the fact we work for The Qt Company, but more 
with the fact that a) you ask us to do the work, and b) to maintain it 

Anyhow, now that we've been both venting our frustration a bit: As Joerg 
already pointed out, I'm completely fine with the patch he has prepared, and 
certainly do hope that distributions make use of it. I'm just disagreeing with 
the request that the Qt documentation need also state 'qmake6' everywhere, and 
that the Qt SDK (as provided by the online installer) needs to contain 
'qmake6', too. 

Kai
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

El mié., 17 feb. 2021 05:33, Joerg Bornemann 
escribió:

>
>
> On 2/17/21 12:47 AM, Lisandro Damián Nicanor Pérez Meyer wrote:
>
>  > Kai: we the maintainers have been asking for the right solution since
> the Qt3 to Qt4 switch.
>
> Obviously not with enough fervor to convince people and in the case of
> Qt6 mch too late in the release process.



In fact the most difficult people to convince are within tqtc. And no, we
have been asking for this change, specifically for qt6, since at very least
2019. And they where no small threads.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Joerg Bornemann]

On 2/16/21 5:36 PM, Thiago Macieira wrote:


We're simply asking that we make official what is already done everywhere.


Yes, and that's all good, and with 
https://codereview.qt-project.org/c/qt/qtbase/+/334054 we will have an 
offical recommendation.
I will also add a documentation page in the vicinity of 
https://doc.qt.io/qt-6/linux-building.html


The only thing we're still arguing about is how to call the tools in the 
documentation.


To mention that the distro-provided qmake might be called qmake6 can 
(and should) also be done. But to change qmake to qmake6 everywhere in 
the docs is as consistent as not doing anything - as long as we don't 
rename the tools.


Python is brought up a lot as the common example for having multiple 
versions installed (though that will be history soonish as python 2 
support fades out). If I look at its documentation 
https://docs.python.org/3/using/cmdline.html there's *one* mention of 
python3, buried in the description of the -X option. Everything else is 
just python.



qmake-based applications that support more than one Qt major version are rare.
Granted, they are more common during the transition period, but since Qt
Company's decision this time to accelerate transition from 5 to 6, it will be
less of an impact this time around. Either way, users need to know whether the
application has been ported to Qt 6 in the first place and the easiest is for
the authors / maintainers to document that you should use "qmake6 ".


$ cat INSTALL
Prerequisites to build AwesomeApp:
   - Qt x.y.z
   - libotherstuff a.b.c
   - ...

Yes, I see the problem but I still doubt its severity.

Renaming just the three tools you mentioned would be inconsistent.
Renaming all tools is too late.


On 2/17/21 12:47 AM, Lisandro Damián Nicanor Pérez Meyer wrote:

> Kai: we the maintainers have been asking for the right solution since 
the Qt3 to Qt4 switch.


Obviously not with enough fervor to convince people and in the case of 
Qt6 mch too late in the release process.



BR,

Joerg
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi Kai.

On Tue, 16 Feb 2021 at 10:34, Kai Köhne  wrote:
[snip]
> To be honest, the whole discussion feels to me that we are being held hostage 
> right now for the fraction of Linux users that cannot use update-alternatives 
> (because they are not administrators). If having different names of tools is 
> such a big problem, why wasn't this addressed by now in Linux itself?

With my maintainer hat on: part of the duty of a maintainer is to
solve issues in the right place. Sometimes is downstreams, in
distributions, and sometimes is directly in the distro.

For this case, as you have seen in other replies, update-alternatives
is just not the right place. And we distribution maintainers have been
trying to solve it at the right place: here, in upstream's code. For
more than a decade now.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Tue, 16 Feb 2021 at 11:37, Ville Voutilainen
 wrote:
>
> On Tue, 16 Feb 2021 at 15:35, Kai Köhne  wrote:
> > And again, this is not something limited to Qt. Last time I checked, the 
> > executable to run Python 3 on Windows is python.exe, not python3.exe. On 
> > Debian at least it's python3. This hasn't blocked Python from being 
> > perceived as overall beginner friendly ...
>
> Uh.. that seems like an apples-and-oranges comparison. On linux, it's
> expected and conventional that if you install both
> python 3 and python 2, both are available in the usual PATH, neither
> eclipses the other, and you can cd between python 2
> and python 3 projects and run both, without switching environments or
> alternatives in between.

Exactly, and that's because you have both python2 and python3
executables on path.

> On windows, I don't know what's conventional. In many cases, a
> shortcut is used that launches a command prompt
> with the right environment, and using two versions in the same command
> prompt just isn't done.

And again, exactly. So comparing against Python on Windows is, as you
say, and apples-and-oranges comparison.

> > So, I would stick to qmake as canonical name, also in the documentation. We 
> > can mention that it's sometimes called qmake6 on Linux. But forcing 
> > everyone to change their habit and scripts just for the sake of consistency 
> > with a fraction of the users that use a global installation on Linux, and 
> > do not use update-alternatives, is IMO not a good move.
>
> update-alternatives is a long-term system-wide configuration change.
> Changing PATH is a shorter-term user-specific one. That's how I switch
> between compilers, and I wouldn't dream of using update-alternatives
> to switch between them. Especially not
> on multi-user systems, where it's none of my business to change the
> alternative used for a system compiler
> for other people. I *can't* do an update-alternatives on a build
> server, and I *shouldn't*. That doesn't mean that
> a build server installation couldn't have both qt 5 and qt 6 installed
> in a system-wide location.
>
> Switching between qt 5 and qt 6 via update-alternatives is Just Wrong.
> If our approach requires it, our approach
> is broken.

And in fact we can use python (again) as a good example: let the
user-facing binaries have the major version in them. And this time the
comparison is on Linux, where it belongs.

Kai: we the maintainers have been asking for the right solution since
the Qt3 to Qt4 switch. For a developer having to add the "6" after the
tool, while it might be a change, it will pretty sure be
straightforward. And by doing this we fix the issue not only for this
release but for every major release here upon.

Tip: many Linux users expect qmake6 or some other variant to call
qmake. Now it's time to make it official *and* consistent for
everyone.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Thiago Macieira]

On Tuesday, 16 February 2021 05:31:17 PST Kai Köhne wrote:
> Well, let's just realize that, by renaming qmake to qmake6 everywhere
> (including in the documentation), we actually create some confusion for our
> existing users, too. Also, I think adding version numbers to the name of
> tools is just no good user experience, and creates unnecessary friction
> when switching between Qt versions.
 
> To be honest, the whole discussion feels to me that we are being held
> hostage right now for the fraction of Linux users that cannot use
> update-alternatives (because they are not administrators). If having
> different names of tools is such a big problem, why wasn't this addressed
> by now in Linux itself?

It has: by renaming our tools. And note the email from the Homebrew folks 
asking the same question. I suspect it hasn't been a problem for them because 
they don't have a Qt 4 recipe in the first place.

Just look at any project and any third-party documentation on how they try to 
find qmake. They try "qmake-qt5" first, then "qmake".

We're simply asking that we make official what is already done everywhere.
 
> And again, this is not something limited to Qt. Last time I checked, the
> executable to run Python 3 on Windows is python.exe, not python3.exe. On
> Debian at least it's python3. This hasn't blocked Python from being
> perceived as overall beginner friendly ...

All Python3 scripts I've EVER seen start with:
#!/usr/bin/python3
OR
#!/usr/bin/env python3

On Windows, there's no /usr/bin, so that doesn't work anyway. Cygwin/MSYS 
environments that do offer such a mount point also offer Python 3 at 
"python3".

Look also at OUR Python scripts (and by "our" I include any and every one from 
our third-party dependencies). All "#!/usr/bin/python" are Python 2 scripts, 
even if there are a few exceptions like "#!/usr/bin/python2.7", and the 
Python3 scripts use "python3" in the name.

FInally, Python has a recommendation: 
https://www.python.org/dev/peps/pep-0394/

Summary:
/usr/bin/python2 is python 2, if installed
/usr/bin/python3 is python 3, if installed
/usr/bin/python is one of the two above and is optional

I am fine if Qt 6 adopts this recommendation.

But note its conclusions: "qmake' can be Qt 5's and "qmake6" is mandatory. 
Therefore, the documentation MUST mention "qmake6".
 
> So, I would stick to qmake as canonical name, also in the documentation. We
> can mention that it's sometimes called qmake6 on Linux. But forcing
> everyone to change their habit and scripts just for the sake of consistency
> with a fraction of the users that use a global installation on Linux, and
> do not use update-alternatives, is IMO not a good move.

The vast majority of people with scripts for applications that support both Qt 
5 and 6 are developers like us who have more than one environment of Qt and 
therefore will do PATH modification when they switch environments.

There are very, very few real applications that support both and come with 
scripts. The majority of those are actually Qt 4 CMake-based applications 
because Qt 4 didn't have CMake files. And note it does search for "qmake-qt4"
(). 
[FindQt.cmake is usually used for Qt 3]

qmake-based applications that support more than one Qt major version are rare. 
Granted, they are more common during the transition period, but since Qt 
Company's decision this time to accelerate transition from 5 to 6, it will be 
less of an impact this time around. Either way, users need to know whether the 
application has been ported to Qt 6 in the first place and the easiest is for 
the authors / maintainers to document that you should use "qmake6 ".

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[André Pönitz]

On Tue, Feb 16, 2021 at 04:35:25PM +0200, Ville Voutilainen wrote:
> On Tue, 16 Feb 2021 at 15:35, Kai Köhne  wrote:
> > And again, this is not something limited to Qt. Last time I checked,
> > the executable to run Python 3 on Windows is python.exe, not
> > python3.exe. On Debian at least it's python3. This hasn't blocked
> > Python from being perceived as overall beginner friendly ...
> 
> Uh.. that seems like an apples-and-oranges comparison. On linux, it's
> expected and conventional that if you install both python 3 and python
> 2, both are available in the usual PATH, neither eclipses the other,
> and you can cd between python 2 and python 3 projects and run both,
> without switching environments or alternatives in between.
> 
> On windows, I don't know what's conventional. In many cases, a
> shortcut is used that launches a command prompt with the right
> environment, and using two versions in the same command prompt just
> isn't done.
> 
> > So, I would stick to qmake as canonical name, also in the
> > documentation. We can mention that it's sometimes called qmake6 on
> > Linux. But forcing everyone to change their habit and scripts just
> > for the sake of consistency with a fraction of the users that use a
> > global installation on Linux, and do not use update-alternatives, is
> > IMO not a good move.
> 
> update-alternatives is a long-term system-wide configuration change.
> Changing PATH is a shorter-term user-specific one. That's how I switch
> between compilers, and I wouldn't dream of using update-alternatives
> to switch between them. Especially not on multi-user systems, where
> it's none of my business to change the alternative used for a system
> compiler for other people. I *can't* do an update-alternatives on a
> build server, and I *shouldn't*. That doesn't mean that a build server
> installation couldn't have both qt 5 and qt 6 installed in a
> system-wide location.
> 
> Switching between qt 5 and qt 6 via update-alternatives is Just Wrong.
> If our approach requires it, our approach is broken.

[Responding to a more or less random mail in the thread here]

I agree that update-alternatives is Just Wrong for something that
should effectively be the user's decision (and not even a decision
for all of the user's projects but something that needs to be done
case-by-case).

On the other hand I don't quite understand all the fuzz about the
Correct Global Name. When I as a user am not happy with someone's
decision on how to name a binary or if a distribution acts funnily or if
I am too lazy to change my muscle memory I set up a shell alias to do
what I want. 

The only problem with that is people looking over my shoulder sometimes
wonder why 'n' brings up firefox or 'gh' starts Qt Creator...

Andre'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Ville Voutilainen]

On Tue, 16 Feb 2021 at 15:35, Kai Köhne  wrote:
> And again, this is not something limited to Qt. Last time I checked, the 
> executable to run Python 3 on Windows is python.exe, not python3.exe. On 
> Debian at least it's python3. This hasn't blocked Python from being perceived 
> as overall beginner friendly ...

Uh.. that seems like an apples-and-oranges comparison. On linux, it's
expected and conventional that if you install both
python 3 and python 2, both are available in the usual PATH, neither
eclipses the other, and you can cd between python 2
and python 3 projects and run both, without switching environments or
alternatives in between.

On windows, I don't know what's conventional. In many cases, a
shortcut is used that launches a command prompt
with the right environment, and using two versions in the same command
prompt just isn't done.

> So, I would stick to qmake as canonical name, also in the documentation. We 
> can mention that it's sometimes called qmake6 on Linux. But forcing everyone 
> to change their habit and scripts just for the sake of consistency with a 
> fraction of the users that use a global installation on Linux, and do not use 
> update-alternatives, is IMO not a good move.

update-alternatives is a long-term system-wide configuration change.
Changing PATH is a shorter-term user-specific one. That's how I switch
between compilers, and I wouldn't dream of using update-alternatives
to switch between them. Especially not
on multi-user systems, where it's none of my business to change the
alternative used for a system compiler
for other people. I *can't* do an update-alternatives on a build
server, and I *shouldn't*. That doesn't mean that
a build server installation couldn't have both qt 5 and qt 6 installed
in a system-wide location.

Switching between qt 5 and qt 6 via update-alternatives is Just Wrong.
If our approach requires it, our approach
is broken.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Shawn Rutledge]

> On 2021 Feb 16, at 14:31, Kai Köhne  wrote:
> 
> Well, let's just realize that, by renaming qmake to qmake6 everywhere 
> (including in the documentation), we actually create some confusion for our 
> existing users, too. Also, I think adding version numbers to the name of 
> tools is just no good user experience, and creates unnecessary friction when 
> switching between Qt versions.
> 
> To be honest, the whole discussion feels to me that we are being held hostage 
> right now for the fraction of Linux users that cannot use update-alternatives 
> (because they are not administrators). If having different names of tools is 
> such a big problem, why wasn't this addressed by now in Linux itself?
> 
> And again, this is not something limited to Qt. Last time I checked, the 
> executable to run Python 3 on Windows is python.exe, not python3.exe. On 
> Debian at least it's python3. This hasn't blocked Python from being perceived 
> as overall beginner friendly ...
> 
> So, I would stick to qmake as canonical name, also in the documentation. We 
> can mention that it's sometimes called qmake6 on Linux. But forcing everyone 
> to change their habit and scripts just for the sake of consistency with a 
> fraction of the users that use a global installation on Linux, and do not use 
> update-alternatives, is IMO not a good move.

I’m not fond of the renaming either.  But as long as the non-suffix tools get 
installed into /usr/lib/qt6/bin and the ones with suffixes are links in 
/usr/bin, it looks like we get a decent compromise.  I’m happy to go on using 
qtchooser and configuring it to point to non-suffix binaries.  But the distros 
need to get in sync to have the suffix be simply 6, not -qt6, IMO.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Tor Arne Vestbø]

> On 16 Feb 2021, at 14:31, Kai Köhne  wrote:
> 
> Well, let's just realize that, by renaming qmake to qmake6 everywhere 
> (including in the documentation), we actually create some confusion for our 
> existing users, too. Also, I think adding version numbers to the name of 
> tools is just no good user experience, and creates unnecessary friction when 
> switching between Qt versions.
> 
> To be honest, the whole discussion feels to me that we are being held hostage 
> right now for the fraction of Linux users that cannot use update-alternatives 
> (because they are not administrators). If having different names of tools is 
> such a big problem, why wasn't this addressed by now in Linux itself?
> 
> And again, this is not something limited to Qt. Last time I checked, the 
> executable to run Python 3 on Windows is python.exe, not python3.exe. On 
> Debian at least it's python3. This hasn't blocked Python from being perceived 
> as overall beginner friendly ...
> 
> So, I would stick to qmake as canonical name, also in the documentation. We 
> can mention that it's sometimes called qmake6 on Linux. But forcing everyone 
> to change their habit and scripts just for the sake of consistency with a 
> fraction of the users that use a global installation on Linux, and do not use 
> update-alternatives, is IMO not a good move.

I fully agree with everything Kai said above. 

Tor Arne

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Kai Köhne]

> -Ursprüngliche Nachricht-
> Von: Development  Im Auftrag von
> Jyrki Yli-Nokari
> Gesendet: Dienstag, 16. Februar 2021 06:10
> An: development@qt-project.org
> Betreff: Re: [Development] Qt 6 co-installability with Qt 5
> 
> Thiago is right. Qt’s biggest problem is the barrier of entry. User facing 
> tools
> must work as documented.

Well, let's just realize that, by renaming qmake to qmake6 everywhere 
(including in the documentation), we actually create some confusion for our 
existing users, too. Also, I think adding version numbers to the name of tools 
is just no good user experience, and creates unnecessary friction when 
switching between Qt versions.

To be honest, the whole discussion feels to me that we are being held hostage 
right now for the fraction of Linux users that cannot use update-alternatives 
(because they are not administrators). If having different names of tools is 
such a big problem, why wasn't this addressed by now in Linux itself?

And again, this is not something limited to Qt. Last time I checked, the 
executable to run Python 3 on Windows is python.exe, not python3.exe. On Debian 
at least it's python3. This hasn't blocked Python from being perceived as 
overall beginner friendly ...

So, I would stick to qmake as canonical name, also in the documentation. We can 
mention that it's sometimes called qmake6 on Linux. But forcing everyone to 
change their habit and scripts just for the sake of consistency with a fraction 
of the users that use a global installation on Linux, and do not use 
update-alternatives, is IMO not a good move.

My 2 cents,

Kai

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Jyrki Yli-Nokari]

Thiago is right. Qt’s biggest problem is the barrier of entry. User facing 
tools must work as documented.

> Thiago Macieira  kirjoitti 16.2.2021 kello 1.15:
> 
> On Monday, 15 February 2021 01:18:16 PST Joerg Bornemann wrote:
>>> To be clear:
>>> 1) the binaries from Qt company must also perform this step
>> 
>> Why? The installer doesn't place binaries into some shared system directory.
> 
> Ok, so long as #2 is done.
> 
>>> 2) the documentation has to be updated to include the "6" at the end too
>> 
>> I disagree.
> 
> This is required. We must teach people to use a set of command-lines that 
> works everywhere. Therefore, the documentation and tutorials about 
> user-public 
> tools should advise them on the commands that work everywhere.
> 
>> Qt's target audience can be split in two groups.
>> 
>> 1. Experienced developers. And I don't even mean Qt-related experience.
>> They're able to figure out to press TAB twice in the shell after typing
>> just "designer" didn't have the desired effect.
>> It's likely, they've been exposed to python before, you know.
> 
> Agreed.
> 
>> 2. Inexperienced developers. They open their desktop search tool of
>> choice and type in "designer", get (perhaps several) hit(s) and choose
>> the right one. They don't even see the oh-so-confusing binary name.
> 
> Fair enough too, though that one is actually more difficult. Just look at 
> what 
> happens when I search for "Proxy" in the attached image. Granted, if I search 
> for "designer" I get an option saying "Qt 5 Designer" so at least our 
> solutions are in the right direction: use the major version number in our 
> descriptions.
> 
>> Maybe you could elaborate why you deem this so important or point to
>> some place in the documentation where we can see the danger of user
>> confusion. Until then, my position is that we're arguing about a non-issue.
> 
> See above.
> 
> I don't care about the tools that aren't meant to be user-visible, because 
> most users won't care about them. Those who do will know how to find them 
> anyway.
> 
> I'm only worried about qmake6, qml6, qtdiag6 and the others that are meant to 
> be user-facing. I can even excuse qml6 and some of the other tools, but I 
> insist on qmake6 and qtdiag6. Documentation must mention the "6".
> 
> If you want to document "try qmake6 and if that doesn't work try qmake", I'm 
> fine. I think that's a mistake, but I'm fine with it.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel DPG Cloud Engineering
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Thiago Macieira]

On Monday, 15 February 2021 01:18:16 PST Joerg Bornemann wrote:
> > To be clear:
> > 1) the binaries from Qt company must also perform this step
> 
> Why? The installer doesn't place binaries into some shared system directory.

Ok, so long as #2 is done.

> > 2) the documentation has to be updated to include the "6" at the end too
> 
> I disagree.

This is required. We must teach people to use a set of command-lines that 
works everywhere. Therefore, the documentation and tutorials about user-public 
tools should advise them on the commands that work everywhere.

> Qt's target audience can be split in two groups.
> 
> 1. Experienced developers. And I don't even mean Qt-related experience.
> They're able to figure out to press TAB twice in the shell after typing
> just "designer" didn't have the desired effect.
> It's likely, they've been exposed to python before, you know.

Agreed.

> 2. Inexperienced developers. They open their desktop search tool of
> choice and type in "designer", get (perhaps several) hit(s) and choose
> the right one. They don't even see the oh-so-confusing binary name.

Fair enough too, though that one is actually more difficult. Just look at what 
happens when I search for "Proxy" in the attached image. Granted, if I search 
for "designer" I get an option saying "Qt 5 Designer" so at least our 
solutions are in the right direction: use the major version number in our 
descriptions.

> Maybe you could elaborate why you deem this so important or point to
> some place in the documentation where we can see the danger of user
> confusion. Until then, my position is that we're arguing about a non-issue.

See above.

I don't care about the tools that aren't meant to be user-visible, because 
most users won't care about them. Those who do will know how to find them 
anyway.

I'm only worried about qmake6, qml6, qtdiag6 and the others that are meant to 
be user-facing. I can even excuse qml6 and some of the other tools, but I 
insist on qmake6 and qtdiag6. Documentation must mention the "6".

If you want to document "try qmake6 and if that doesn't work try qmake", I'm 
fine. I think that's a mistake, but I'm fine with it.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Joerg Bornemann]

On 2/12/21 8:28 PM, Thiago Macieira wrote:

On Friday, 12 February 2021 01:21:39 PST Joerg Bornemann wrote:

Each line of user_facing_tool_links.txt consists of the installation
path of a user-facing application followed by a space and the versioned
link name in INSTALL_PUBLICBINDIR.


To be clear:
1) the binaries from Qt company must also perform this step


Why? The installer doesn't place binaries into some shared system directory.


2) the documentation has to be updated to include the "6" at the end too


I disagree.

Qt's target audience can be split in two groups.

1. Experienced developers. And I don't even mean Qt-related experience. 
They're able to figure out to press TAB twice in the shell after typing 
just "designer" didn't have the desired effect.

It's likely, they've been exposed to python before, you know.

2. Inexperienced developers. They open their desktop search tool of 
choice and type in "designer", get (perhaps several) hit(s) and choose 
the right one. They don't even see the oh-so-confusing binary name.


Maybe you could elaborate why you deem this so important or point to 
some place in the documentation where we can see the danger of user 
confusion. Until then, my position is that we're arguing about a non-issue.



Cheers,

Joerg
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Thiago Macieira]

On Friday, 12 February 2021 01:21:39 PST Joerg Bornemann wrote:
> Each line of user_facing_tool_links.txt consists of the installation
> path of a user-facing application followed by a space and the versioned
> link name in INSTALL_PUBLICBINDIR.

To be clear:
1) the binaries from Qt company must also perform this step
2) the documentation has to be updated to include the "6" at the end too

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Fri, 12 Feb 2021 at 06:22, Joerg Bornemann  wrote:
>
> Hi,
>
> here comes an update on the status of co-installability of Qt5 and Qt6.
>
> For the main issue QTBUG-89170, I've created
> https://codereview.qt-project.org/c/qt/qtbase/+/334054
> Package maintainers, please review this patch.
>
> Let me paste parts of the commit message to fill you in what this is about.

great!

>
> Apart from that, we still plan to move the non-user-facing tools to
> libexec. QTBUG-88791 tracks this.
> Patch is here: https://codereview.qt-project.org/c/qt/qtbase/+/331332

Looking at the comments in there: installing to libexec instead of
bindir by default is, in my point of view, a good idea.

Thanks a lot!
-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Joerg Bornemann]

Hi,

here comes an update on the status of co-installability of Qt5 and Qt6.

For the main issue QTBUG-89170, I've created 
https://codereview.qt-project.org/c/qt/qtbase/+/334054

Package maintainers, please review this patch.

Let me paste parts of the commit message to fill you in what this is about.

---snip---
When packaging different Qt versions for Linux distributions (or any
distribution with a common bin dir), Qt tools cannot be installed to
/usr/bin, because the executable names of the different Qt versions
clash.

To solve this conflict, our recommendation is to install Qt's tools to
/usr/qt6/bin and to create versioned symlinks to user-facing tools in
/usr/bin.

User-facing tools are tools that are supposed to be started manually by
the user. They are marked in Qt's build system. Distro package
maintainers can now configure with
  -DCMAKE_INSTALL_PREFIX=/usr
  -DINSTALL_BINDIR=/usr/qt6/bin
  -DINSTALL_PUBLICBINDIR=/usr/bin
and will find a file called user_facing_tool_links.txt in the build
directory after the cmake run. Nothing will be installed to
INSTALL_PUBLICBINDIR.

Each line of user_facing_tool_links.txt consists of the installation
path of a user-facing application followed by a space and the versioned
link name in INSTALL_PUBLICBINDIR.

Example content:
/usr/qt6/bin/qmake /usr/bin/qmake6

To actually create the versioned symlinks, the content of this file can
be fed to ln like this:
  xargs ln -s < build-dir/user_facing_tool_links.txt

Or the package maintainer may decide to do something completely
different as suits their needs.
---snap---

Apart from that, we still plan to move the non-user-facing tools to 
libexec. QTBUG-88791 tracks this.

Patch is here: https://codereview.qt-project.org/c/qt/qtbase/+/331332



Cheers,

Joerg
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Thu, 10 Dec 2020 at 13:13, Kai Köhne  wrote:

>
>
> > -Original Message-
> > From: Development  On Behalf Of
> > Thiago Macieira
> > Sent: Thursday, December 10, 2020 3:48 PM
> > To: development@qt-project.org
> > Subject: Re: [Development] Qt 6 co-installability with Qt 5
> >
> > On Wednesday, 9 December 2020 23:24:00 PST Kai Köhne wrote:
> > > Consistency is important, but is it really so that people struggle
> > > with realizing that 'linguist' is 'linguist6' in their local Linux
> installation?
> > >
> > > If this is really a problem we can consider just mentioning both names
> > > in the documentation.
> >
> > We should mention only one: linguist6.
>
> I disagree.
>

I agree with Thiago. Having both Qt 5 and Qt 6 versions installed at the
same time will be a common thing for most users, and we will receive lots
of "bugs" due to that. The documentation then need to call the right tool.
And yes, I have seen that before lots of times (remember -qt5 in qtchooser?)

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Kai Köhne]

> -Original Message-
> From: Development  On Behalf Of
> Thiago Macieira
> Sent: Thursday, December 10, 2020 3:48 PM
> To: development@qt-project.org
> Subject: Re: [Development] Qt 6 co-installability with Qt 5
> 
> On Wednesday, 9 December 2020 23:24:00 PST Kai Köhne wrote:
> > Consistency is important, but is it really so that people struggle
> > with realizing that 'linguist' is 'linguist6' in their local Linux 
> > installation?
> >
> > If this is really a problem we can consider just mentioning both names
> > in the documentation.
> 
> We should mention only one: linguist6.

I disagree.

Anyhow, we only talk about 'Qt Linguist' in the documentation, not 
linguist(qt-)?6?(.exe)? , or Qt Linguist.app. So this point is actually mood, 
at least for Qt Linguist 


Kai
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Thiago Macieira]

On Wednesday, 9 December 2020 23:24:00 PST Kai Köhne wrote:
> Consistency is important, but is it really so that people struggle with
> realizing that 'linguist' is 'linguist6' in their local Linux installation?
> 
> If this is really a problem we can consider just mentioning both names in
> the documentation.

We should mention only one: linguist6.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Kai Köhne]

> -Original Message-
> From: Development  On Behalf Of
> Lisandro Damián Nicanor Pérez Meyer
> [...]
> > We do that already, it's just not enough for user-facing applications. I'll 
> > be
> more verbose on the bug report if needed.
> 
> The problem of options 2 and 3 are that they do not talk about
> documentation. Documentation should call user-facing tools with the 6 prefix
> too. That also means that it will change in other operative systems, so
> symlinks might not be the real cross platform solution.

Consistency is important, but is it really so that people struggle with 
realizing that 'linguist' is 'linguist6' in their local Linux installation?

If this is really a problem we can consider just mentioning both names in the 
documentation.

Kai

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Tue, 8 Dec 2020 at 10:51, Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
[snip]
> We do that already, it's just not enough for user-facing applications. I'll 
> be more verbose on the bug report if needed.

The problem of options 2 and 3 are that they do not talk about
documentation. Documentation should call user-facing tools with the 6
prefix too. That also means that it will change in other operative
systems, so symlinks might not be the real cross platform solution.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

El mar., 8 dic. 2020 08:23, Alexandru Croitor 
escribió:

> Hi,
>
> Please check the following comment on JIRA
>
> https://bugreports.qt.io/browse/QTBUG-89170?focusedCommentId=541242
>
> And whether the proposed "approach 3" suits you.
>
> It seems to work already for Christophe's packages as they commented on
> the issue.
>
> The remaining part would be providing the reference shell script that
> creates the symlinks.
>


We do that already, it's just not enough for user-facing applications. I'll
be more verbose on the bug report if needed.

>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

El lun., 7 dic. 2020 16:52, Joerg Bornemann 
escribió:

> On 10/27/20 5:34 PM, Thiago Macieira wrote:
>
> > Have we fixed it?
>
> The discussion apparently petered out as everytime this came up - or
> maybe I just missed that we now have consensus on how to name things and
> where to put stuff?
>
> Kai created https://bugreports.qt.io/browse/QTBUG-89170 to track this.
>
> Please make sure that it is sound and suits your needs.
>


If I remember correctly Thiago proposed a QUIP. I just couldn't even start
one because end of year + deadlines under COVID circumstances didn't left
me more time left.

But thanks a lot for the pointer!!!

>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Alexandru Croitor]

Hi,

Please check the following comment on JIRA

https://bugreports.qt.io/browse/QTBUG-89170?focusedCommentId=541242

And whether the proposed "approach 3" suits you.

It seems to work already for Christophe's packages as they commented on the 
issue.

The remaining part would be providing the reference shell script that creates 
the symlinks.


> On 7. Dec 2020, at 20:50, Joerg Bornemann  wrote:
> 
> On 10/27/20 5:34 PM, Thiago Macieira wrote:
> 
>> Have we fixed it?
> 
> The discussion apparently petered out as everytime this came up - or maybe I 
> just missed that we now have consensus on how to name things and where to put 
> stuff?
> 
> Kai created https://bugreports.qt.io/browse/QTBUG-89170 to track this.
> 
> Please make sure that it is sound and suits your needs.
> 
> 
> Cheers,
> 
> Joerg
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Joerg Bornemann]

On 10/27/20 5:34 PM, Thiago Macieira wrote:


Have we fixed it?


The discussion apparently petered out as everytime this came up - or 
maybe I just missed that we now have consensus on how to name things and 
where to put stuff?


Kai created https://bugreports.qt.io/browse/QTBUG-89170 to track this.

Please make sure that it is sound and suits your needs.


Cheers,

Joerg
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Matthew Woehlke]

On 18/11/2020 07.34, Lisandro Damián Nicanor Pérez Meyer wrote:

Possibly also:

assistant6 for reading Qt 6 help files when not using Qt Creator
designer6  for those not using Qt Creator and needing to use Qt 6 plugins

Offtopic, but I wonder how much those standalone apps are still being used 
today.


designer: a lot, specially if your screen does not has enough
resolution to use it embedded within Qt Creator. That's exactly my
case (yes, I sadly still have an old machine, the same I used in Qt
5.0 times ;-) )


Ahem: not everyone uses Creator! (Yeah, okay, fine, I think KDevelop can 
embed it also, but I still typically use it stand-alone .)


--
Matthew
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Kai Pastor, DG0YT via Development]

Am 19.11.20 um 08:20 schrieb Kai Köhne:

Am 18.11.20 um 15:50 schrieb Kai Köhne:

FYI, we've been taking assistant out of Qt 6.0.
https://bugreports.qt.io/browse/QTBUG-86746 . It's not depending on
any particular Qt version, so my suggestion is to resurrect it (if
there's enough demand) outside of qt5.git.

Could you please clarify: Can building Qt Asistant be enabled by a
configuration option? Is it still build as part of CI?

Currently not. I think it should be completely removed from qttools - disabling 
the build was just the quickest way for the 6.0 release.


I wouldn't mind if Assistant would actually be moved to a different 
repository. But so far, it is only a suggestion.



Now with all Qt help links changed to the online version, how is Qt
Assistant/QTextBrowser limiting Qt's documentation at all, justifying its
removal from the build (so late in the Qt 6 release process)?

The reason why we removed Qt Assistant in the beta phase is that I don't think 
it should be part of Qt 6.


Do you want to remove it from "Qt 6", from "Qt 6.0", or from "Qt 6.0.0"? 
There has been no deprecation of this Qt feature AFAIK.


If you want to remove it from "Qt 6", then there is no need for CI.

Regards,
Kai

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Kai Köhne]

> -Original Message-
> From: Development  On Behalf Of Kai
> Pastor, DG0YT via Development
> Sent: Thursday, November 19, 2020 7:03 AM
> To: development@qt-project.org
> Subject: Re: [Development] Qt 6 co-installability with Qt 5
> 
> Am 18.11.20 um 15:50 schrieb Kai Köhne:
> > FYI, we've been taking assistant out of Qt 6.0.
> > https://bugreports.qt.io/browse/QTBUG-86746 . It's not depending on
> > any particular Qt version, so my suggestion is to resurrect it (if
> > there's enough demand) outside of qt5.git.
> 
> Could you please clarify: Can building Qt Asistant be enabled by a
> configuration option? Is it still build as part of CI?

Currently not. I think it should be completely removed from qttools - disabling 
the build was just the quickest way for the 6.0 release.

> Now with all Qt help links changed to the online version, how is Qt
> Assistant/QTextBrowser limiting Qt's documentation at all, justifying its
> removal from the build (so late in the Qt 6 release process)?

The reason why we removed Qt Assistant in the beta phase is that I don't think 
it should be part of Qt 6.

Regards

Kai

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Kai Pastor, DG0YT via Development]

Am 18.11.20 um 15:50 schrieb Kai Köhne:
FYI, we've been taking assistant out of Qt 6.0. 
https://bugreports.qt.io/browse/QTBUG-86746 . It's not depending on 
any particular Qt version, so my suggestion is to resurrect it (if 
there's enough demand) outside of qt5.git. 


Could you please clarify: Can building Qt Asistant be enabled by a 
configuration option? Is it still build as part of CI?


Now with all Qt help links changed to the online version, how is Qt 
Assistant/QTextBrowser limiting Qt's documentation at all, justifying 
its removal from the build (so late in the Qt 6 release process)?


Regards,
Kai

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Ulf Hermann]

qml6   I don't understand why, but I'm told it's necessary
[...]


If we consider QML to be a general purpose scripting or UI prototyping 
language, then we should keep this easily accessible to end users. You 
can write QML-only applications or scripts and then use the qml(6) tool 
to run them.


qml(6) should be preferred over qmlscene(6). We've been trying to get 
rid of qmlscene for a while now.


best regards,
Ulf

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

On Wed, 18 Nov 2020 at 13:45, Thiago Macieira  wrote:
>
> On Wednesday, 18 November 2020 04:34:40 PST Lisandro Damián Nicanor Pérez >
> > So basically:
> >
> > - Move out of $prefix/bin (and thus out of $PATH) every developer-oriented
> > tool.
> > - Ensure that user-facing applications will be backwards compatible
> > with Qt 5 for all the Qt 6 timeline.
>
> I don't think that will work for qmake6 (see below). I am willing to accept
> this for all other (developer) tools.
>
> As for user-facing, here's the litmus test: the application can be moved out
> of the Qt repositories into one of its own. And then we do exactly that.
> Preferably also removing the use of private API in the process.

That would be simply awesome.

> We've long had the question about translators wanting to install Linguist, but
> the only installation we have of it is the full Qt, which requires a compiler
> to also be present. Instead, we should provide translators with an installable
> Linguist using the Installer Framework for Windows, a macdeployqt bundle in a
> .dmg for Macs and, if we're feeling adventurous, a FlatPak for Linux.
>
> > But then I wonder if designer shouldn't stay on $PATH or not. Because
> > even if it's a developer tool it's one expected to be on $PATH much
> > like Qt Creator. The developer tools that can stay out of $PATH are
> > the ones that can be easily callable from within toolchains (qmake,
> > cmake, etc). But then again we distros could simply make a
> > $prefix/bin/designer6 symlink. Telling our users "just use designer6"
> > it's really not a big deal, even if the docs just say "designer".
>
> That's not an option. The docs must say either:
> a) "run designer6"
> or
> b) "run /bin/designer"

In that case I would prefer (a) because it's situation is almost the
same as the qmake one you describe below.

> > > qmake6 entry point for building qmake-based applications,
> > > situation
> > >
> > >similar to /usr/bin/python (see [1])
> > >
> > > I am not yet 100% convinced it is. This is a build tool after all, and
> > > even changes with minor versions of Qt. I know Linux distributions do
> > > only ship one minor version, but many of our users have to manage
> > > multiple minor versions of Qt as well. And renaming qmake with every
> > > minor version is a no-go.
> > Well, that's the exact opposite reply I've got (from Ossi?) on Qt 5.0
> > times. qmake needed to be on path in order to be able to query it for
> > some paths. But if that's no longer the case then yes, it can stay
> > away.
>
> qmake6 needs to be on PATH because that's how we will tell people how to build
> their applications. Telling users to go discover where their Linux
> distributions installed Qt6 is not acceptable, in my point of view.

Agreed, that's why I followed my initial mail comparing it to CMake,
I've just realized it later.

And I think a tool like designer should follow the same path.

> In any case, since we *need* qtdiag6 and qtpaths6, I don't see what's the harm
> in having qmake6 too.
>
> > > qml6   I don't understand why, but I'm told it's necessary
> > >
> > >
> > > It’s a runtime for running qml files without a C++ entry point. But we can
> > > actually decide that this is a developer oriented tool and not have it
> > > linked into /usr/bin.
> > Still a tool that is expected to be called by humans though. And then
> > again we could easily keep a $prefix/bin/qml6 link.
>
> I don't care enough. I'm sure I haven't run this tool in 3 years. I even
> thought "qmlscene" was the one we were supposed to run since 5.0...
>
> I'm just following what has been said in this thread that some people do run
> it.
>
> > > All of those are developer facing tools and shouldn’t be in /usr/bin at
> > > all IMO.
> > And again, they could be easily symlinked with a prefix if needed.
>
> I'd like to come to a consensus so that every installation follows procedure
> and is supported by docs. I'd rather Linux distributions didn't feel the need
> to start adding more symlinks.

Right.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Thiago Macieira]

On Wednesday, 18 November 2020 04:34:40 PST Lisandro Damián Nicanor Pérez > 
> So basically:
> 
> - Move out of $prefix/bin (and thus out of $PATH) every developer-oriented
> tool. 
> - Ensure that user-facing applications will be backwards compatible
> with Qt 5 for all the Qt 6 timeline.

I don't think that will work for qmake6 (see below). I am willing to accept 
this for all other (developer) tools. 

As for user-facing, here's the litmus test: the application can be moved out 
of the Qt repositories into one of its own. And then we do exactly that. 
Preferably also removing the use of private API in the process.

We've long had the question about translators wanting to install Linguist, but 
the only installation we have of it is the full Qt, which requires a compiler 
to also be present. Instead, we should provide translators with an installable 
Linguist using the Installer Framework for Windows, a macdeployqt bundle in a 
.dmg for Macs and, if we're feeling adventurous, a FlatPak for Linux.

> But then I wonder if designer shouldn't stay on $PATH or not. Because
> even if it's a developer tool it's one expected to be on $PATH much
> like Qt Creator. The developer tools that can stay out of $PATH are
> the ones that can be easily callable from within toolchains (qmake,
> cmake, etc). But then again we distros could simply make a
> $prefix/bin/designer6 symlink. Telling our users "just use designer6"
> it's really not a big deal, even if the docs just say "designer".

That's not an option. The docs must say either:
a) "run designer6"
or 
b) "run /bin/designer"

> > qmake6 entry point for building qmake-based applications,
> > situation
> > 
> >similar to /usr/bin/python (see [1])
> > 
> > I am not yet 100% convinced it is. This is a build tool after all, and
> > even changes with minor versions of Qt. I know Linux distributions do
> > only ship one minor version, but many of our users have to manage
> > multiple minor versions of Qt as well. And renaming qmake with every
> > minor version is a no-go.
> Well, that's the exact opposite reply I've got (from Ossi?) on Qt 5.0
> times. qmake needed to be on path in order to be able to query it for
> some paths. But if that's no longer the case then yes, it can stay
> away.

qmake6 needs to be on PATH because that's how we will tell people how to build 
their applications. Telling users to go discover where their Linux 
distributions installed Qt6 is not acceptable, in my point of view.

In any case, since we *need* qtdiag6 and qtpaths6, I don't see what's the harm 
in having qmake6 too.

> > qml6   I don't understand why, but I'm told it's necessary
> > 
> > 
> > It’s a runtime for running qml files without a C++ entry point. But we can
> > actually decide that this is a developer oriented tool and not have it
> > linked into /usr/bin.
> Still a tool that is expected to be called by humans though. And then
> again we could easily keep a $prefix/bin/qml6 link.

I don't care enough. I'm sure I haven't run this tool in 3 years. I even 
thought "qmlscene" was the one we were supposed to run since 5.0...

I'm just following what has been said in this thread that some people do run 
it.

> > All of those are developer facing tools and shouldn’t be in /usr/bin at
> > all IMO.
> And again, they could be easily symlinked with a prefix if needed.

I'd like to come to a consensus so that every installation follows procedure 
and is supported by docs. I'd rather Linux distributions didn't feel the need 
to start adding more symlinks.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Thiago Macieira]

On Wednesday, 18 November 2020 06:50:12 PST Kai Köhne wrote:
> FYI, we've been taking assistant out of Qt 6.0.
> https://bugreports.qt.io/browse/QTBUG-86746 . It's not depending on any
> particular Qt version, so my suggestion is to resurrect it (if there's
> enough demand) outside of qt5.git.

Agreed, provided it can load both Qt5 and Qt6 documents.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

On Wed, 18 Nov 2020 at 11:04, Tor Arne Vestbø  wrote:
[snip]
>> qdbus can be called by an app ran by an end-user.
> That sounds like a deployment issue. If the app needs qdbus, it needs to 
> bundle it, or make sure it knows the full path to it (but that sounds like a 
> fragile thing to rely on).

Embedding is something that distributions avoid. Getting the full path
is possible if exposed somehow (like a CMake variable that holds the
path), but it also means the developer must do "the right thing".

> Besides, shouldn’t an app using dbus use 
> https://doc.qt.io/qt-5/qtdbus-index.html and not an external binary?

Maybe, but there seems to be use cases:

https://sources.debian.org/src/plasma-workspace/4:5.19.5-5/wallpapers/image/wallpaper.knsrc.cmake/?hl=49#L49

just to name one.

> So (#1) is mostly (fully?) cleared, then we still have (#2.1).
>
>
> Okey, good to get #1 out of the way first. Thanks!

Thanks to you! This really helps everyone discuss the issue!


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Tor Arne Vestbø]

On 18 Nov 2020, at 14:21, Lisandro Damián Nicanor Pérez Meyer 
mailto:perezme...@gmail.com>> wrote:

On Wed, 18 Nov 2020 at 10:16, Tor Arne Vestbø 
mailto:tor.arne.ves...@qt.io>> wrote:



On 18 Nov 2020, at 14:01, Lisandro Damián Nicanor Pérez Meyer 
mailto:perezme...@gmail.com>> wrote:

On Wed, 18 Nov 2020 at 09:58, Tor Arne Vestbø 
mailto:tor.arne.ves...@qt.io>> wrote:
[snip]
Let’s clarify this, so we’re talking about the same thing:

1. Application end-users
2. Application developers using Qt
3. Qt developers

Let me expand it:

1. Application end-users
2.1. Application developers using Qt as provided by distro.
2.2. Application developers using more than one Qt major/minor version.
3. Qt developers.

#3 develops Qt for use by #2 to produce applications for #1

When you are talking about end users, which one of these do you refer to?

1 and 2.1.

The application end user (#1) shouldn’t need access to any of Qt’s binaries 
AFAIK. What’s there for us to fix for them?

qdbus can be called by an app ran by an end-user.

That sounds like a deployment issue. If the app needs qdbus, it needs to bundle 
it, or make sure it knows the full path to it (but that sounds like a fragile 
thing to rely on). Besides, shouldn’t an app using dbus use 
https://doc.qt.io/qt-5/qtdbus-index.html and not an external binary?

So (#1) is mostly (fully?) cleared, then we still have (#2.1).

Okey, good to get #1 out of the way first. Thanks!

Tor Arne
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

On Wed, 18 Nov 2020 at 10:16, Tor Arne Vestbø  wrote:
>
>
>
> > On 18 Nov 2020, at 14:01, Lisandro Damián Nicanor Pérez Meyer 
> >  wrote:
> >
> > On Wed, 18 Nov 2020 at 09:58, Tor Arne Vestbø  wrote:
> > [snip]
> >> Let’s clarify this, so we’re talking about the same thing:
> >>
> >> 1. Application end-users
> >> 2. Application developers using Qt
> >> 3. Qt developers
> >
> > Let me expand it:
> >
> > 1. Application end-users
> > 2.1. Application developers using Qt as provided by distro.
> > 2.2. Application developers using more than one Qt major/minor version.
> > 3. Qt developers.
> >
> >> #3 develops Qt for use by #2 to produce applications for #1
> >>
> >> When you are talking about end users, which one of these do you refer to?
> >
> > 1 and 2.1.
>
> The application end user (#1) shouldn’t need access to any of Qt’s binaries 
> AFAIK. What’s there for us to fix for them?

qdbus can be called by an app ran by an end-user. Yes, it's a
backwards-compatible tool so nothing to worry with that specific tool
(in fact this thread helped to clear down the tools that need to be
backwards compatible).

So (#1) is mostly (fully?) cleared, then we still have (#2.1).


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Tor Arne Vestbø]

> On 18 Nov 2020, at 14:01, Lisandro Damián Nicanor Pérez Meyer 
>  wrote:
> 
> On Wed, 18 Nov 2020 at 09:58, Tor Arne Vestbø  wrote:
> [snip]
>> Let’s clarify this, so we’re talking about the same thing:
>> 
>> 1. Application end-users
>> 2. Application developers using Qt
>> 3. Qt developers
> 
> Let me expand it:
> 
> 1. Application end-users
> 2.1. Application developers using Qt as provided by distro.
> 2.2. Application developers using more than one Qt major/minor version.
> 3. Qt developers.
> 
>> #3 develops Qt for use by #2 to produce applications for #1
>> 
>> When you are talking about end users, which one of these do you refer to?
> 
> 1 and 2.1.

The application end user (#1) shouldn’t need access to any of Qt’s binaries 
AFAIK. What’s there for us to fix for them? 

Cheers,
Tor Arne 

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

On Wed, 18 Nov 2020 at 10:01, Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
> On Wed, 18 Nov 2020 at 09:58, Tor Arne Vestbø  wrote:
> [snip]
> > Let’s clarify this, so we’re talking about the same thing:
> >
> >  1. Application end-users
> >  2. Application developers using Qt
> >  3. Qt developers
>
> Let me expand it:
>
> 1. Application end-users
> 2.1. Application developers using Qt as provided by distro.
> 2.2. Application developers using more than one Qt major/minor version.
> 3. Qt developers.

Maybe worth mentioning: 2.2 should probably be "more than one minor
version", I am assuming that 2.1 covers both Qt 5 and 6.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

On Wed, 18 Nov 2020 at 09:58, Tor Arne Vestbø  wrote:
[snip]
> Let’s clarify this, so we’re talking about the same thing:
>
>  1. Application end-users
>  2. Application developers using Qt
>  3. Qt developers

Let me expand it:

1. Application end-users
2.1. Application developers using Qt as provided by distro.
2.2. Application developers using more than one Qt major/minor version.
3. Qt developers.

> #3 develops Qt for use by #2 to produce applications for #1
>
> When you are talking about end users, which one of these do you refer to?

1 and 2.1.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Tor Arne Vestbø]

On 18 Nov 2020, at 13:39, Lisandro Damián Nicanor Pérez Meyer 
mailto:perezme...@gmail.com>> wrote:

Right, and this are all developer's tools. End users shouldn't care
nor even know about them. Remember, we are talking about
distribution-provided binaries.

Let’s clarify this, so we’re talking about the same thing:

 1. Application end-users
 2. Application developers using Qt
 3. Qt developers

#3 develops Qt for use by #2 to produce applications for #1

When you are talking about end users, which one of these do you refer to?

Cheers,
Tor Arne
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

On Wed, 18 Nov 2020 at 09:34, Lisandro Damián Nicanor Pérez Meyer
 wrote:
[snip]
> > Then there's the question of which tools we recommend be in $PATH with a
> > suffix (list (b)). Please expand on this list if necessary, with a reason.
> > Here's the minimum list:
> >
> > qmake6 entry point for building qmake-based applications, situation
> >similar to /usr/bin/python (see [1])
> >
> >
> > I am not yet 100% convinced it is. This is a build tool after all, and even 
> > changes with minor versions of Qt. I know Linux distributions do only ship 
> > one minor version, but many of our users have to manage multiple minor 
> > versions of Qt as well. And renaming qmake with every minor version is a 
> > no-go.
>
> Well, that's the exact opposite reply I've got (from Ossi?) on Qt 5.0
> times. qmake needed to be on path in order to be able to query it for
> some paths. But if that's no longer the case then yes, it can stay
> away.

...but using the same rationale that would also mean that tools like
cmake shouldn't be on path, which is not true. And yes, we could
simply symlink qmake6 but I think that, for this very specific tool,
the name should be qmake6 in docs too, at least on Linux.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Wed, 18 Nov 2020 at 08:58, Tor Arne Vestbø  wrote:
>
>
> On 18 Nov 2020, at 12:11, Tor Arne Vestbø  wrote:
>
> What we need is a command line tool for doing the same. That’s how other 
> project solve things too (nvm, rvm, pyenv, etc)
>
>
> For some context:
>
> https://github.com/nvm-sh/nvm
> https://rvm.io/
> https://github.com/rbenv/rbenv/
> https://github.com/pyenv/pyenv
> https://doc.rust-lang.org/edition-guide/rust-2018/rustup-for-managing-rust-versions.html
> https://github.com/kylef/swiftenv
>
> Some of these tools modify PATH on behalf of the user, while others add a 
> custom directory to the PATH where they then swap symlinks around (which is 
> how qtchooser works as far as I know?).
>
> They also allow per project (local) version pinning, which can be useful.

Right, and this are all developer's tools. End users shouldn't care
nor even know about them. Remember, we are talking about
distribution-provided binaries.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi Tor!

On Wed, 18 Nov 2020 at 08:13, Tor Arne Vestbø  wrote:
>
> Morning,
>
> IMHO, suffixing our binaries is a kludge. It “solves” the major version 
> transition, but not any of the other use cases such as minor version 
> upgrades, different builds of the same Qt version, etc.

It's only about solving the major version, ie, the end-users version
provided by distributions. The cases you mention are mostly
developer-oriented.

> Qt Creator already provides a way to manage and switch Qt versions: 
> https://doc.qt.io/qtcreator/creator-project-qmake.html

Not everyone uses Creator.

> What we need is a command line tool for doing the same. That’s how other 
> project solve things too (nvm, rvm, pyenv, etc). And we already have a tool 
> for that, qtchooser. If maintenance of that is an issue, then let’s solve 
> that.
>
> Why is that not an acceptable solution for distros?

Because it breaks things:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=qtchooser and form
that list specially
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712264 which is a
per-design bug, ie, it can't be solved.

That doesn't means developers can still use it though.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi Lars!

On Wed, 18 Nov 2020 at 08:03, Lars Knoll  wrote:
[snip]
> Thinking a bit more about this, I wonder how many applications _really_ need 
> a version.
>
> To start with, I think it’s important to recognise a difference between 
> developer oriented tools and tools targeting end users.
>
> Most of our developer oriented tools are (or can be) dependent on the exact 
> version of Qt installed. Thus the problem is larger than just a Qt 5 vs Qt 6 
> thing.
>
> Those tools should just stay in a version specific directory and should IMO 
> not be exposed in the generic path for end users (moc should for example 
> never end up in /usr/bin). Instead the correct version is found by the build 
> system and called from there. And developers needing direct access to them 
> should adjust their path to include those tools.

Well, that's a huge change from what was discussed before, specially
when I brought this topic in Qt 5.0 (which I had forgotten, Thiago
made me remember). Yes, of course, if we can decide that most of the
tools are for developers only and can live outside $prefix/bin then
it's definitely another way to solve this issue. And in fact it might
be a much better solution.

So basically:

- Move out of $prefix/bin (and thus out of $PATH) every developer-oriented tool.
- Ensure that user-facing applications will be backwards compatible
with Qt 5 for all the Qt 6 timeline.

> For most end user facing tools, I wonder whether we actually need to support 
> co-installation. The examples listed just below (linguist etc.) are backwards 
> compatible, and it should be ok to simply install the latest version, similar 
> to what is done with qtcreator.

Yes if backwards compatibility is assured. Last time we discussed this
(for 5.0 if my memory does not fails me) designer was considered a
tool that needed to be on $PATH. When Qt5's designer arrived it
supported Qt4's plugins... for some time.

But then I wonder if designer shouldn't stay on $PATH or not. Because
even if it's a developer tool it's one expected to be on $PATH much
like Qt Creator. The developer tools that can stay out of $PATH are
the ones that can be easily callable from within toolchains (qmake,
cmake, etc). But then again we distros could simply make a
$prefix/bin/designer6 symlink. Telling our users "just use designer6"
it's really not a big deal, even if the docs just say "designer".

[snip]
> Then there's the question of which tools we recommend be in $PATH with a
> suffix (list (b)). Please expand on this list if necessary, with a reason.
> Here's the minimum list:
>
> qmake6 entry point for building qmake-based applications, situation
>similar to /usr/bin/python (see [1])
>
>
> I am not yet 100% convinced it is. This is a build tool after all, and even 
> changes with minor versions of Qt. I know Linux distributions do only ship 
> one minor version, but many of our users have to manage multiple minor 
> versions of Qt as well. And renaming qmake with every minor version is a 
> no-go.

Well, that's the exact opposite reply I've got (from Ossi?) on Qt 5.0
times. qmake needed to be on path in order to be able to query it for
some paths. But if that's no longer the case then yes, it can stay
away.

> qml6   I don't understand why, but I'm told it's necessary
>
>
> It’s a runtime for running qml files without a C++ entry point. But we can 
> actually decide that this is a developer oriented tool and not have it linked 
> into /usr/bin.

Still a tool that is expected to be called by humans though. And then
again we could easily keep a $prefix/bin/qml6 link.

> qtdiag6entry point for debugging problems with Qt 6
> qtpaths6   because knowing the path in order to run the tool to get
>paths sounds weird. Having this in $PATH allows us to
>help users get to the other, debugging tools (qtplugininfo,
>qmlplugindump, etc.)
>
> Possibly also:
>
> assistant6 for reading Qt 6 help files when not using Qt Creator
> designer6  for those not using Qt Creator and needing to use Qt 6 plugins
>
>
> Offtopic, but I wonder how much those standalone apps are still being used 
> today.

designer: a lot, specially if your screen does not has enough
resolution to use it embedded within Qt Creator. That's exactly my
case (yes, I sadly still have an old machine, the same I used in Qt
5.0 times ;-) )

> Also agreed. I would consider assistant6 and designer6 to be included
> in list (b) due to past experience.
>
> Tools I don't know if they should or shouldn't be in this list:
>
> - pixeltool: it's a screen magnifier, never used it before, but
> clearly not something used at build time. Sounds like a user-facing
> app for me.
>
> - qtplugininfo: I sincerely don't know how it's being used.
>
> - qtwaylandscanner: same as above.
>
> - tracegen: same as above
>
> - sdpscanner: "Performs an SDP scan on remote device, using the SDP server
> represented by the local 

Re: [Development] Qt 6 co-installability with Qt 5

[Giuseppe D'Angelo via Development]

Il 18/11/20 12:03, Lars Knoll ha scritto:


- tracegen: same as above


Is tracegen of any usage outside Qt itself?

Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Wed, 18 Nov 2020 at 06:02, Joerg Bornemann  wrote:
>
> On 11/18/20 12:49 AM, Lisandro Damián Nicanor Pérez Meyer wrote:
>
> >> You need to have a host Qt installed, including qmake.
> >> The cross-built Qt's qmake is a wrapper script that calls the host Qt's
> >> qmake and passes a qt.conf file, adjusting qmake's properties.
> >> This wrapper script in the cross-built Qt is currently named "qmake" and
> >> currently lives in $prefix/bin.
> >
> > Sounds like $prefix/bin/qmake6 is feasible, even maybe *always* a
> > script that calls the host's qmake installed in $bindir except when
> > passed the right qt.conf file. Would that work? That would also mean
> > avoiding installing the real qmake in $prefix/bin and it's prefix.
>
> $prefix/bin/qmake6 can also be a wrapper script, sure.
> What would be the advantage of not installing the actual qmake binary there?

None, I've realized it after sending the mail.



-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Tor Arne Vestbø]

On 18 Nov 2020, at 12:11, Tor Arne Vestbø 
mailto:tor.arne.ves...@qt.io>> wrote:

What we need is a command line tool for doing the same. That’s how other 
project solve things too (nvm, rvm, pyenv, etc)

For some context:

  *   https://github.com/nvm-sh/nvm
  *   https://rvm.io/
  *   https://github.com/rbenv/rbenv/
  *   https://github.com/pyenv/pyenv
  *   
https://doc.rust-lang.org/edition-guide/rust-2018/rustup-for-managing-rust-versions.html
  *   https://github.com/kylef/swiftenv

Some of these tools modify PATH on behalf of the user, while others add a 
custom directory to the PATH where they then swap symlinks around (which is how 
qtchooser works as far as I know?).

They also allow per project (local) version pinning, which can be useful.

Tor Arne






___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Tor Arne Vestbø]

Morning,

IMHO, suffixing our binaries is a kludge. It “solves” the major version 
transition, but not any of the other use cases such as minor version upgrades, 
different builds of the same Qt version, etc.

Qt Creator already provides a way to manage and switch Qt versions: 
https://doc.qt.io/qtcreator/creator-project-qmake.html

What we need is a command line tool for doing the same. That’s how other 
project solve things too (nvm, rvm, pyenv, etc). And we already have a tool for 
that, qtchooser. If maintenance of that is an issue, then let’s solve that.

Why is that not an acceptable solution for distros?

Tor Arne

On 27 Oct 2020, at 17:34, Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:

Have we fixed it?

I do not plan on updating qtchooser for Qt 6. Qt 6 should not install any
binary with the same name as Qt 5 did.

--
Thiago Macieira - thiago.macieira (AT) intel.com
 Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lars Knoll]

On 18 Nov 2020, at 00:41, Lisandro Damián Nicanor Pérez Meyer 
mailto:perezme...@gmail.com>> wrote:

On Tue, 17 Nov 2020 at 14:09, Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:

On Tuesday, 27 October 2020 09:34:44 PST Thiago Macieira wrote:
Have we fixed it?

I do not plan on updating qtchooser for Qt 6. Qt 6 should not install any
binary with the same name as Qt 5 did.

Lars and I just had a quick discussion on IRC about this and here's what we
propose. Ground rules and caveats:

1) MOST tools do not need to be in $PATH for most users. We developers are not
most users. For us, setting PATH is acceptable. We're also likely the only
audience to have more than one 5.x or 6.x Qt version installed.

2) This recommendation need not be supported by the buildsystem in time for
6.0.0, but needs to be as early as possible and by 6.1 at the latest. This
recommendation allows Linux distributions to apply workarounds meanwhile,
other buildsystems to adjust (read: Meson), and for us to write docs and QUIP.

3) there's a question of cross-compilation relating to qmake and host tools,
which I have not followed and do not understand the current state of. Need
input here.

With that in mind, our recommendation is as follows:

a) ALL tools be installed to a binary directory that is not $prefix/bin
b) SOME tools be symlinked/hardlinked/stubbed into $prefix/bin, with a suffix
 (we recommend a simple "6" instead of "-qt6")
c) ADDITIONALLY, some further tools can be present unsuffixed

Thinking a bit more about this, I wonder how many applications _really_ need a 
version.

To start with, I think it’s important to recognise a difference between 
developer oriented tools and tools targeting end users.

Most of our developer oriented tools are (or can be) dependent on the exact 
version of Qt installed. Thus the problem is larger than just a Qt 5 vs Qt 6 
thing.

Those tools should just stay in a version specific directory and should IMO not 
be exposed in the generic path for end users (moc should for example never end 
up in /usr/bin). Instead the correct version is found by the build system and 
called from there. And developers needing direct access to them should adjust 
their path to include those tools.

For most end user facing tools, I wonder whether we actually need to support 
co-installation. The examples listed just below (linguist etc.) are backwards 
compatible, and it should be ok to simply install the latest version, similar 
to what is done with qtcreator.

Once we have that, the question is what is left that actually has to have a 
versioned name?


The question is what tools are those in lists (b) and (c). Starting with the
easiest (c):
- linguist
- qdbus
- qdbusviewer

Those are user-facing tools that definitely do not depend on Qt version. It's
up to the implementer to decide which Qt version they want these tools to be
and any choice is fine. My guess is that for two of the three, it will depend
mostly on Look-and-Feel with the desktop. But since these are an implementer's
choice, Qt installation never installs those tools with the unsuffixed names
by default.

Agreed to all above.

Then there's the question of which tools we recommend be in $PATH with a
suffix (list (b)). Please expand on this list if necessary, with a reason.
Here's the minimum list:

qmake6 entry point for building qmake-based applications, situation
   similar to /usr/bin/python (see [1])

I am not yet 100% convinced it is. This is a build tool after all, and even 
changes with minor versions of Qt. I know Linux distributions do only ship one 
minor version, but many of our users have to manage multiple minor versions of 
Qt as well. And renaming qmake with every minor version is a no-go.

qml6   I don't understand why, but I'm told it's necessary

It’s a runtime for running qml files without a C++ entry point. But we can 
actually decide that this is a developer oriented tool and not have it linked 
into /usr/bin.

qtdiag6entry point for debugging problems with Qt 6
qtpaths6   because knowing the path in order to run the tool to get
   paths sounds weird. Having this in $PATH allows us to
   help users get to the other, debugging tools (qtplugininfo,
   qmlplugindump, etc.)

Possibly also:

assistant6 for reading Qt 6 help files when not using Qt Creator
designer6  for those not using Qt Creator and needing to use Qt 6 plugins

Offtopic, but I wonder how much those standalone apps are still being used 
today.

Also agreed. I would consider assistant6 and designer6 to be included
in list (b) due to past experience.

Tools I don't know if they should or shouldn't be in this list:

- pixeltool: it's a screen magnifier, never used it before, but
clearly not something used at build time. Sounds like a user-facing
app for me.

- qtplugininfo: I sincerely don't know how it's being used.

- qtwaylandscanner: same as above.

- tracegen: same as 

Re: [Development] Qt 6 co-installability with Qt 5

[Joerg Bornemann]

On 11/18/20 12:41 AM, Lisandro Damián Nicanor Pérez Meyer wrote:


Tools I don't know if they should or shouldn't be in this list:

- pixeltool: it's a screen magnifier, never used it before, but
clearly not something used at build time. Sounds like a user-facing
app for me.


That's not a tool for the user of Qt.
This is used for squinting at UI elements when debugging visual issues.


Cheers,

Joerg
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Joerg Bornemann]

On 11/18/20 12:49 AM, Lisandro Damián Nicanor Pérez Meyer wrote:


You need to have a host Qt installed, including qmake.
The cross-built Qt's qmake is a wrapper script that calls the host Qt's
qmake and passes a qt.conf file, adjusting qmake's properties.
This wrapper script in the cross-built Qt is currently named "qmake" and
currently lives in $prefix/bin.


Sounds like $prefix/bin/qmake6 is feasible, even maybe *always* a
script that calls the host's qmake installed in $bindir except when
passed the right qt.conf file. Would that work? That would also mean
avoiding installing the real qmake in $prefix/bin and it's prefix.


$prefix/bin/qmake6 can also be a wrapper script, sure.
What would be the advantage of not installing the actual qmake binary there?


Cheers,

Joerg
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Sune Vuorela]

On 2020-11-17, Kai Köhne  wrote:
> Why should the packages in the online installer change? They are hardly ever 
> installed into some general directory.

To have documentation be "Run this command `foo`". not "If you are
running linux or mac and have gotten your Qt the normal way thru your
packagemanager, run `foo-qt6`, if you are on windows or have done the qt
installer, run `foo`"

/Sune

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

On Tue, 17 Nov 2020 at 21:13, Thiago Macieira  wrote:
>
> On Tuesday, 17 November 2020 15:41:10 PST Lisandro Damián Nicanor Pérez Meyer
> wrote:
> > - qtplugininfo: I sincerely don't know how it's being used.
>
> I was going to suggest it, but I ended up thinking it was obscure enough that
> for anyone who really needs it, they can use
>
> `qtpaths6 --binaries-dir`/qtplugininfo
>
> > - qtwaylandscanner: same as above.
> >
> > - tracegen: same as above
>
> Ditto and even less likely to be used.
>
> > - sdpscanner: "Performs an SDP scan on remote device, using the SDP server
> > represented by the local Bluetooth device." Sounds like a user-facing app.
>
> True, but it also sounds very limited. It sounds like an example application
> that is quite useful for the limited scenarios where it can be used. Like my
> cbordump tool too. Ditto for pixeltool.

Totally sensible.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Thiago Macieira]

On Tuesday, 17 November 2020 15:41:10 PST Lisandro Damián Nicanor Pérez Meyer 
wrote:
> - qtplugininfo: I sincerely don't know how it's being used.

I was going to suggest it, but I ended up thinking it was obscure enough that 
for anyone who really needs it, they can use 

`qtpaths6 --binaries-dir`/qtplugininfo

> - qtwaylandscanner: same as above.
> 
> - tracegen: same as above

Ditto and even less likely to be used.

> - sdpscanner: "Performs an SDP scan on remote device, using the SDP server
> represented by the local Bluetooth device." Sounds like a user-facing app.

True, but it also sounds very limited. It sounds like an example application 
that is quite useful for the limited scenarios where it can be used. Like my 
cbordump tool too. Ditto for pixeltool.

I'd suggest that qdbusviewer and qdbus be moved out of the Qt repositories and 
made separate releases of their own. They use private API, but so do a lot of 
KDE applications and frameworks. But we can think about that later.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

On Tue, 17 Nov 2020 at 17:31, Joerg Bornemann  wrote:
>
> On 11/17/20 6:07 PM, Thiago Macieira wrote:
>
> > 3) there's a question of cross-compilation relating to qmake and host tools,
> > which I have not followed and do not understand the current state of. Need
> > input here.
>
> The situation is as follows for the cross-building case:
>
> You need to have a host Qt installed, including qmake.
> The cross-built Qt's qmake is a wrapper script that calls the host Qt's
> qmake and passes a qt.conf file, adjusting qmake's properties.
> This wrapper script in the cross-built Qt is currently named "qmake" and
> currently lives in $prefix/bin.

Sounds like $prefix/bin/qmake6 is feasible, even maybe *always* a
script that calls the host's qmake installed in $bindir except when
passed the right qt.conf file. Would that work? That would also mean
avoiding installing the real qmake in $prefix/bin and it's prefix.

By the way this is more or less how cross compiling Qt 5 apps with
Debian's multiarch was achieved: we use a generic mkspec but
automatically-generated qt.conf files.

Anyways this is a really interesting thing to consider as it might
make cross compiling easier within distributions that can co-install
the necessary stuff.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

On Tue, 17 Nov 2020 at 14:09, Thiago Macieira  wrote:
>
> On Tuesday, 27 October 2020 09:34:44 PST Thiago Macieira wrote:
> > Have we fixed it?
> >
> > I do not plan on updating qtchooser for Qt 6. Qt 6 should not install any
> > binary with the same name as Qt 5 did.
>
> Lars and I just had a quick discussion on IRC about this and here's what we
> propose. Ground rules and caveats:
>
> 1) MOST tools do not need to be in $PATH for most users. We developers are not
> most users. For us, setting PATH is acceptable. We're also likely the only
> audience to have more than one 5.x or 6.x Qt version installed.
>
> 2) This recommendation need not be supported by the buildsystem in time for
> 6.0.0, but needs to be as early as possible and by 6.1 at the latest. This
> recommendation allows Linux distributions to apply workarounds meanwhile,
> other buildsystems to adjust (read: Meson), and for us to write docs and QUIP.
>
> 3) there's a question of cross-compilation relating to qmake and host tools,
> which I have not followed and do not understand the current state of. Need
> input here.
>
> With that in mind, our recommendation is as follows:
>
> a) ALL tools be installed to a binary directory that is not $prefix/bin
> b) SOME tools be symlinked/hardlinked/stubbed into $prefix/bin, with a suffix
>   (we recommend a simple "6" instead of "-qt6")
> c) ADDITIONALLY, some further tools can be present unsuffixed
>
> The question is what tools are those in lists (b) and (c). Starting with the
> easiest (c):
>  - linguist
>  - qdbus
>  - qdbusviewer
>
> Those are user-facing tools that definitely do not depend on Qt version. It's
> up to the implementer to decide which Qt version they want these tools to be
> and any choice is fine. My guess is that for two of the three, it will depend
> mostly on Look-and-Feel with the desktop. But since these are an implementer's
> choice, Qt installation never installs those tools with the unsuffixed names
> by default.

Agreed to all above.

> Then there's the question of which tools we recommend be in $PATH with a
> suffix (list (b)). Please expand on this list if necessary, with a reason.
> Here's the minimum list:
>
>  qmake6 entry point for building qmake-based applications, situation
> similar to /usr/bin/python (see [1])
>  qml6   I don't understand why, but I'm told it's necessary
>  qtdiag6entry point for debugging problems with Qt 6
>  qtpaths6   because knowing the path in order to run the tool to get
> paths sounds weird. Having this in $PATH allows us to
> help users get to the other, debugging tools (qtplugininfo,
> qmlplugindump, etc.)
>
> Possibly also:
>
>  assistant6 for reading Qt 6 help files when not using Qt Creator
>  designer6  for those not using Qt Creator and needing to use Qt 6 plugins

Also agreed. I would consider assistant6 and designer6 to be included
in list (b) due to past experience.

Tools I don't know if they should or shouldn't be in this list:

- pixeltool: it's a screen magnifier, never used it before, but
clearly not something used at build time. Sounds like a user-facing
app for me.

- qtplugininfo: I sincerely don't know how it's being used.

- qtwaylandscanner: same as above.

- tracegen: same as above

- sdpscanner: "Performs an SDP scan on remote device, using the SDP server
represented by the local Bluetooth device." Sounds like a user-facing app.



-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Thiago Macieira]

On Tuesday, 17 November 2020 13:14:08 PST Joerg Bornemann wrote:
> On 11/17/20 9:50 PM, Thiago Macieira wrote:
> >> qt-cmake6
> >> 
> >>   entry point for building CMake-based Qt-applications
> > 
> > Why is this not simply cmake?
> 
> Right. For the host Qt in /usr/... this is most probably not needed and
> could just be cmake using the global search paths.

Then we don't need that in $PATH. This script can be one more build helper in 
the internal bin dir.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Joerg Bornemann]

On 11/17/20 9:50 PM, Thiago Macieira wrote:


qt-cmake6
  entry point for building CMake-based Qt-applications


Why is this not simply cmake?


Right. For the host Qt in /usr/... this is most probably not needed and 
could just be cmake using the global search paths.



Joerg
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Thiago Macieira]

On Tuesday, 17 November 2020 12:30:53 PST Joerg Bornemann wrote:
> qt-cmake6
>  entry point for building CMake-based Qt-applications

Why is this not simply cmake?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Joerg Bornemann]

On 11/17/20 6:07 PM, Thiago Macieira wrote:


3) there's a question of cross-compilation relating to qmake and host tools,
which I have not followed and do not understand the current state of. Need
input here.


The situation is as follows for the cross-building case:

You need to have a host Qt installed, including qmake.
The cross-built Qt's qmake is a wrapper script that calls the host Qt's 
qmake and passes a qt.conf file, adjusting qmake's properties.
This wrapper script in the cross-built Qt is currently named "qmake" and 
currently lives in $prefix/bin.



Then there's the question of which tools we recommend be in $PATH with a
suffix (list (b)). Please expand on this list if necessary, with a reason.
Here's the minimum list:

  qmake6entry point for building qmake-based applications, 
situation
similar to /usr/bin/python (see [1])


qt-cmake6
entry point for building CMake-based Qt-applications

possibly

qt-configure-module6
entry point for building Qt modules that are not part of the 
installation


But one might argue that whoever wants to build a Qt module can call 
this script from libexec.



BR,

Joerg
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Thiago Macieira]

On Tuesday, 27 October 2020 09:34:44 PST Thiago Macieira wrote:
> Have we fixed it?
> 
> I do not plan on updating qtchooser for Qt 6. Qt 6 should not install any
> binary with the same name as Qt 5 did.

Lars and I just had a quick discussion on IRC about this and here's what we 
propose. Ground rules and caveats:

1) MOST tools do not need to be in $PATH for most users. We developers are not 
most users. For us, setting PATH is acceptable. We're also likely the only 
audience to have more than one 5.x or 6.x Qt version installed.

2) This recommendation need not be supported by the buildsystem in time for 
6.0.0, but needs to be as early as possible and by 6.1 at the latest. This 
recommendation allows Linux distributions to apply workarounds meanwhile, 
other buildsystems to adjust (read: Meson), and for us to write docs and QUIP.

3) there's a question of cross-compilation relating to qmake and host tools, 
which I have not followed and do not understand the current state of. Need 
input here.

With that in mind, our recommendation is as follows:

a) ALL tools be installed to a binary directory that is not $prefix/bin
b) SOME tools be symlinked/hardlinked/stubbed into $prefix/bin, with a suffix
  (we recommend a simple "6" instead of "-qt6")
c) ADDITIONALLY, some further tools can be present unsuffixed

The question is what tools are those in lists (b) and (c). Starting with the 
easiest (c):
 - linguist
 - qdbus
 - qdbusviewer

Those are user-facing tools that definitely do not depend on Qt version. It's 
up to the implementer to decide which Qt version they want these tools to be 
and any choice is fine. My guess is that for two of the three, it will depend 
mostly on Look-and-Feel with the desktop. But since these are an implementer's 
choice, Qt installation never installs those tools with the unsuffixed names 
by default.

Then there's the question of which tools we recommend be in $PATH with a 
suffix (list (b)). Please expand on this list if necessary, with a reason. 
Here's the minimum list:

 qmake6 entry point for building qmake-based applications, situation
similar to /usr/bin/python (see [1])
 qml6   I don't understand why, but I'm told it's necessary
 qtdiag6entry point for debugging problems with Qt 6
 qtpaths6   because knowing the path in order to run the tool to get 
paths sounds weird. Having this in $PATH allows us to
help users get to the other, debugging tools (qtplugininfo,
qmlplugindump, etc.)

Possibly also:

 assistant6 for reading Qt 6 help files when not using Qt Creator
 designer6  for those not using Qt Creator and needing to use Qt 6 plugins

We may want to have more suffixes and more stubbing, symlinking, such as what 
exists for LLVM in some distros:

lrwxrwxrwx 1 root root 14 nov  3 02:54 /usr/bin/clang++-10 -> clang++-10.0.1
lrwxrwxrwx 1 root root 14 nov  3 02:54 /usr/bin/clang++-10.0 -> clang++-10.0.1
lrwxrwxrwx 1 root root 12 nov  3 02:54 /usr/bin/clang++-10.0.1 -> clang-10.0.1
lrwxrwxrwx 1 root root 14 nov  2 07:58 /usr/bin/clang++-11 -> clang++-11.0.0
lrwxrwxrwx 1 root root 14 nov  2 07:58 /usr/bin/clang++-11.0 -> clang++-11.0.0
lrwxrwxrwx 1 root root 12 nov  2 07:58 /usr/bin/clang++-11.0.0 -> clang-11.0.0
lrwxrwxrwx 1 root root 12 nov  3 02:54 /usr/bin/clang-10 -> clang-10.0.1
lrwxrwxrwx 1 root root 12 nov  3 02:54 /usr/bin/clang-10.0 -> clang-10.0.1
lrwxrwxrwx 1 root root 12 nov  2 07:58 /usr/bin/clang-11 -> clang-11.0.0
lrwxrwxrwx 1 root root 12 nov  2 07:58 /usr/bin/clang-11.0 -> clang-11.0.0

Note: LLVM is NOT a good example in most ways. I do know OpenSUSE heavily 
patches the LLVM build to get reasonable library names, CMake files and 
binaries. I did the same in [2].

[1] https://www.python.org/dev/peps/pep-0394/
[2] https://github.com/clearlinux-pkgs/llvm9/blob/master/install_append
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Thiago Macieira]

On Tuesday, 17 November 2020 07:49:14 PST Lisandro Damián Nicanor Pérez Meyer 
wrote:
> > Why should the packages in the online installer change? They are hardly
> > ever installed into some general directory.
> Because it sets precedence. This way tools will expect the prefix on Linux.

Also because other people build application that work with both Linux 
distribution packages and those provided by qt.io. Their work needs to work 
with both, somehow.

> > Also, this most likely will set us back in the release process. Doing
> > large-scale renames at RC time is just asking for trouble. Let's consider
> > this in time for Qt 7.
> And then someone will push the topic again and Qt fails to "see  it"
> again, thus delayed to Qt 8.
> 
> Come on Kai, please realize it is **not** a new issue. In fact I
> pushed this exact thing **two** years ago and then insisted on it
> exactly to avoid this resolution.

And we discussed this for Qt 5.0 too.

Anyway, Lars and I are trying to come up with a proposal, right now on #qt-
labs.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Tue, 17 Nov 2020 at 12:31, Kai Köhne  wrote:
>
> > -Original Message-
> > From: Development  On Behalf Of
> > Thiago Macieira
> >> On Tuesday, 17 November 2020 00:46:32 PST Joerg Bornemann wrote:
> >> It is certainly possible to add a further configure option a la
> >>  -qt-executable-suffix -qt6
> >> to move the burden from the packagers to Qt's build system and ensure
> >> consistent Qt installation layouts across distributions.> That's a good 
> >> solution, so long as the packages built from qt.io also use it.
> > Can we count on that?
>
> Why should the packages in the online installer change? They are hardly ever 
> installed into some general directory.

Because it sets precedence. This way tools will expect the prefix on Linux.

> Also, this most likely will set us back in the release process. Doing 
> large-scale renames at RC time is just asking for trouble. Let's consider 
> this in time for Qt 7.

And then someone will push the topic again and Qt fails to "see  it"
again, thus delayed to Qt 8.

Come on Kai, please realize it is **not** a new issue. In fact I
pushed this exact thing **two** years ago and then insisted on it
exactly to avoid this resolution.

If you (Qt company) do not really like it, then go ahead and say"we
don't care about distributions". Or just bite the bullet and do the
right thing: get those binaries renamed (or a method to do it).



-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Kai Köhne]

> -Original Message-
> From: Development  On Behalf Of
> Thiago Macieira
>> On Tuesday, 17 November 2020 00:46:32 PST Joerg Bornemann wrote:
>> It is certainly possible to add a further configure option a la
>>  -qt-executable-suffix -qt6
>> to move the burden from the packagers to Qt's build system and ensure 
>> consistent Qt installation layouts across distributions.> That's a good 
>> solution, so long as the packages built from qt.io also use it.
> Can we count on that?

Why should the packages in the online installer change? They are hardly ever 
installed into some general directory.

Also, this most likely will set us back in the release process. Doing 
large-scale renames at RC time is just asking for trouble. Let's consider this 
in time for Qt 7.

Kai
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Thiago Macieira]

On Tuesday, 17 November 2020 07:05:10 PST Thiago Macieira wrote:
> On Tuesday, 17 November 2020 03:42:50 PST Kevin Kofler via Development 
wrote:
> > I have not yet talked to those who will likely be the maintainers of Qt 6
> > in Fedora, but this is almost exactly how things already work in Fedora
> > for Qt 4 and 5 (except that we use hardlinks instead of symlinks due to
> > multilib issues, as I explained elsewhere in this thread), so I think
> > that is the most likely setup for Qt 6 as well (but Fedora will probably
> > continue to use hardlinks).
> 
> Anyone willing to submit a patch to rename the tools and to install no
> unrenamed naeme?

Actually, never mind this. See (upcoming) post from the top of the thread.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Thiago Macieira]

On Tuesday, 17 November 2020 00:46:32 PST Joerg Bornemann wrote:
> It is certainly possible to add a further configure option a la
>  -qt-executable-suffix -qt6
> to move the burden from the packagers to Qt's build system and ensure
> consistent Qt installation layouts across distributions.

That's a good solution, so long as the packages built from qt.io also use it. 
Can we count on that?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Thiago Macieira]

On Tuesday, 17 November 2020 03:42:50 PST Kevin Kofler via Development wrote:
> I have not yet talked to those who will likely be the maintainers of Qt 6 in
> Fedora, but this is almost exactly how things already work in Fedora for Qt
> 4 and 5 (except that we use hardlinks instead of symlinks due to multilib
> issues, as I explained elsewhere in this thread), so I think that is the
> most likely setup for Qt 6 as well (but Fedora will probably continue to
> use hardlinks).

Anyone willing to submit a patch to rename the tools and to install no 
unrenamed naeme?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Tue, 17 Nov 2020 at 08:43, Kevin Kofler via Development
 wrote:
>
> Lisandro Damián Nicanor Pérez Meyer wrote:
> > I've discussed this with Dmitry Shachnev and the simplest way to
> > "solve" this would be to ship binaries in /usr/lib/qt6/bin/foo and
> > have /usr/bin/foo-qt6 symlinks to those.
>
> I have not yet talked to those who will likely be the maintainers of Qt 6 in
> Fedora, but this is almost exactly how things already work in Fedora for Qt
> 4 and 5 (except that we use hardlinks instead of symlinks due to multilib
> issues, as I explained elsewhere in this thread), so I think that is the
> most likely setup for Qt 6 as well (but Fedora will probably continue to use
> hardlinks).

ACK, I did contact Rex Dieter on IRC, so we have an agreement here.
The links being hard/soft are just a packaging detail in this case.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi Joerg!

On Tue, 17 Nov 2020 at 05:49, Joerg Bornemann  wrote:
>
> On 11/13/20 8:24 PM, Sune Vuorela wrote:
>
> > Oh. And I'm surprised by the Qt-people sudden love of QtChooser
> There's no sudden love. Just surprise that all of a sudden, shortly
> before the release, the established solution for co-installability must
> be changed.

I have brought this issue at very least two years ago:

https://development.qt-project.narkive.com/l84BEF6M/qt6-qt5-coinstallability-linux-distributions

And I'm pretty sure I did revive the topic at least one or two more
times, so no, there is nothing new here.

> It is certainly possible to add a further configure option a la
>  -qt-executable-suffix -qt6
> to move the burden from the packagers to Qt's build system and ensure
> consistent Qt installation layouts across distributions.
>
> However, simply changing the executable names won't cut it.
> I expect breakages, esp. in the qmake support. Therefore, this won't
> happen for 6.0.0.
>
> Please come up with a proposal that fits the packagers needs for the
> different distros, and we'll see how we can incorporate that into the
> build system.

Provide user-facing applications with a suitable prefix. That's all
that's needed. Tools that are only used at build time do not need the
prefix.



-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Joerg Bornemann]

On 11/13/20 8:24 PM, Sune Vuorela wrote:


Oh. And I'm surprised by the Qt-people sudden love of QtChooser
There's no sudden love. Just surprise that all of a sudden, shortly 
before the release, the established solution for co-installability must 
be changed.


It is certainly possible to add a further configure option a la
-qt-executable-suffix -qt6
to move the burden from the packagers to Qt's build system and ensure 
consistent Qt installation layouts across distributions.


However, simply changing the executable names won't cut it.
I expect breakages, esp. in the qmake support. Therefore, this won't 
happen for 6.0.0.


Please come up with a proposal that fits the packagers needs for the 
different distros, and we'll see how we can incorporate that into the 
build system.



Cheers,

Joerg
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Thiago Macieira]

On Friday, 13 November 2020 11:24:49 PST Sune Vuorela wrote:
> I also think it is sane to 1) EOL Qt Chooser.

As the qtchooser maintainer. I am declaring it EOL and have closed the 
remaining open tasks.

I hereby also resign maintaining it too.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Sune Vuorela]

On 2020-11-02, Lars Knoll  wrote:
> I honestly don't think renaming all our binaries is an option, certainly not 
> that late in the process. We’ve had Qt 4 and Qt 5 co-installed for a long 
> time as well and while that might not be perfect it was working.
>
> And qtchooser has been working nicely for me (Ubuntu at least uses it).

I pushed quite hard to use it Debian (and ubuntu inherited it), but it
is also a tool that from a packaging perspective gets in the way. Gives
surprises. and weird systems for people.

I also think it is sane to 1) EOL Qt Chooser. 2) Add version numbers to
all public facing executables. (See also e.g. python2 vs python3). and
3) and do it in Qt so that distros are constistent with eachother, with
windows, with mac, and with the Qt documentation.

Oh. And I'm surprised by the Qt-people sudden love of QtChooser - I had
a quite hard battle getting just rudimentary support into Creator to
support the Qt's setup there.

/Sune

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Thu, 12 Nov 2020 at 20:29, Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
> Hi!
>
> On Wed, 11 Nov 2020 at 12:55, Thiago Macieira  
> wrote:
> >
> > On Monday, 9 November 2020 09:57:13 PST Lisandro Damián Nicanor Pérez Meyer
> > wrote:
> > > Seriously, we have discussed this before, and we kind of agreed that
> > > user-facing applications should either be really backwards compatible
> > > or should have the tool suffixed with the qt version. Whatever other
> > > option is just pain for maintainers, be it trough qtchooser or by
> > > letting us renaming tools ourselves.
> >
> > Lisandro, Kevin, other packagers in the list:
> >
> > May I suggest you get together and make a proposal? If you can get a patch
> > into Gerrit, great. If not, then post the cmake command-line that Linux
> > distributions will use. We need the distributions to be consistent with each
> > other.
> >
> > Post to this list what the Qt 6 Linux distributions packages will install 
> > and
> > what the layout will be. Whether the default builds do the same or not is
> > irrelevant. It's your choice and can go against the default build.
> >
> > This is important for KDE Frameworks 6 and other software that mostly builds
> > from distro packages will likely adopt for its reference documentation.
>
> I like the idea. I have not touched Qt 6 yet (I'm very sadly not going
> to be able to maintain it) but I think this is actually a nice thing
> to do. I'll reach my co-maintainers and ask there. Kevin: can you do
> the same?

I've discussed this with Dmitry Shachnev and the simplest way to
"solve" this would be to ship binaries in /usr/lib/qt6/bin/foo and
have /usr/bin/foo-qt6 symlinks to those.

Projects using CMake to build will have no issues at all. If KDE
people need to call a user-facing application they might get the path
from CMake too.

Note that I used the -qt6 suffix here because I think that's what most
distros have been doing, but we have no opposition to any other suffix
scheme if necessary.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Wed, 11 Nov 2020 at 12:55, Thiago Macieira  wrote:
>
> On Monday, 9 November 2020 09:57:13 PST Lisandro Damián Nicanor Pérez Meyer
> wrote:
> > Seriously, we have discussed this before, and we kind of agreed that
> > user-facing applications should either be really backwards compatible
> > or should have the tool suffixed with the qt version. Whatever other
> > option is just pain for maintainers, be it trough qtchooser or by
> > letting us renaming tools ourselves.
>
> Lisandro, Kevin, other packagers in the list:
>
> May I suggest you get together and make a proposal? If you can get a patch
> into Gerrit, great. If not, then post the cmake command-line that Linux
> distributions will use. We need the distributions to be consistent with each
> other.
>
> Post to this list what the Qt 6 Linux distributions packages will install and
> what the layout will be. Whether the default builds do the same or not is
> irrelevant. It's your choice and can go against the default build.
>
> This is important for KDE Frameworks 6 and other software that mostly builds
> from distro packages will likely adopt for its reference documentation.

I like the idea. I have not touched Qt 6 yet (I'm very sadly not going
to be able to maintain it) but I think this is actually a nice thing
to do. I'll reach my co-maintainers and ask there. Kevin: can you do
the same?


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Thiago Macieira]

On Monday, 9 November 2020 09:57:13 PST Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Seriously, we have discussed this before, and we kind of agreed that
> user-facing applications should either be really backwards compatible
> or should have the tool suffixed with the qt version. Whatever other
> option is just pain for maintainers, be it trough qtchooser or by
> letting us renaming tools ourselves.

Lisandro, Kevin, other packagers in the list:

May I suggest you get together and make a proposal? If you can get a patch 
into Gerrit, great. If not, then post the cmake command-line that Linux 
distributions will use. We need the distributions to be consistent with each 
other.

Post to this list what the Qt 6 Linux distributions packages will install and 
what the layout will be. Whether the default builds do the same or not is 
irrelevant. It's your choice and can go against the default build.

This is important for KDE Frameworks 6 and other software that mostly builds 
from distro packages will likely adopt for its reference documentation.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi again!

On Mon, 9 Nov 2020 at 15:51, Shawn Rutledge  wrote:
>
>
>
> > On 9 Nov 2020, at 19:27, Shawn Rutledge  wrote:
> >
> >
> >> On 2 Nov 2020, at 17:15, Thiago Macieira  wrote:
> >> ]qml is like Python: because of plugins, it's tied to the Qt version.
> >> Therefore, it fails the requirement for supporting everything the old 
> >> version
> >> supported.
> >
> > Well if you were using modules that are no longer supported, or you run 
> > into some little incompatibility; but we have been trying to avoid API 
> > breaks.  QML files that begin with “import QtQuick 2.0” still work fine so 
> > far; also Controls, Layouts etc.  So IMO it’s less onerous than the python 
> > upgrade.
>
> … but your point was not about QML file compatibility but about the mere fact 
> that we have a BC break, so users need two versions of the qml interpreter 
> installed at the same time, right?  And I still rather like the idea of just 
> installing them in different
> places, and having a symlink to point to the one you want to use.  If distro 
> maintainers insist that /usr/bin/qml must be an executable and not a symlink, 
> then I guess it should be the Qt 6 version, to go along with the fact that 
> we’re pushing the open source
> community pretty hard to upgrade as soon as it’s released.

If the qml binary is **only** used at build time then yes, it can be
hidden. If it's used as a script interpreter then you need to provide
both at the same time, because even in the fastest Qt 6 adoption times
you will have to support both Qt 5 and 6 versions for at very least 6
years. Believe me, I did that with Qt 4 and 5 :-)



-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Shawn Rutledge]

> On 9 Nov 2020, at 19:27, Shawn Rutledge  wrote:
> 
> 
>> On 2 Nov 2020, at 17:15, Thiago Macieira  wrote:
>> ]qml is like Python: because of plugins, it's tied to the Qt version. 
>> Therefore, it fails the requirement for supporting everything the old 
>> version 
>> supported. 
> 
> Well if you were using modules that are no longer supported, or you run into 
> some little incompatibility; but we have been trying to avoid API breaks.  
> QML files that begin with “import QtQuick 2.0” still work fine so far; also 
> Controls, Layouts etc.  So IMO it’s less onerous than the python upgrade.

… but your point was not about QML file compatibility but about the mere fact 
that we have a BC break, so users need two versions of the qml interpreter 
installed at the same time, right?  And I still rather like the idea of just 
installing them in different places, and having a symlink to point to the one 
you want to use.  If distro maintainers insist that /usr/bin/qml must be an 
executable and not a symlink, then I guess it should be the Qt 6 version, to go 
along with the fact that we’re pushing the open source community pretty hard to 
upgrade as soon as it’s released.  The Qt 5 version of qml can be hidden in 
another directory, because users who are developing new software presumably 
don’t need it too often anymore.  As for shebang scripts… I will admit that 
they are probably scarce, because we haven’t publicized this feature much.  And 
even if some people wrote them, many of those should still work.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Mon, 9 Nov 2020 at 15:28, Shawn Rutledge  wrote:
>
>
> > On 2 Nov 2020, at 17:15, Thiago Macieira  wrote:
> > ]qml is like Python: because of plugins, it's tied to the Qt version.
> > Therefore, it fails the requirement for supporting everything the old 
> > version
> > supported.
>
> Well if you were using modules that are no longer supported, or you run into 
> some little incompatibility; but we have been trying to avoid API breaks.  
> QML files that begin with “import QtQuick 2.0” still work fine so far; also 
> Controls, Layouts etc.  So IMO it’s less onerous than the python upgrade.I 
> *think* that in this point we are talking about plugins within QML modules. 
> Can a Qt6 QML module be used in a Qt 5 application or the other way around? I 
> think the answer is no. And if the answer is no you need to be able to co 
> install this two different versions.



-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Shawn Rutledge]

> On 2 Nov 2020, at 17:15, Thiago Macieira  wrote:
> ]qml is like Python: because of plugins, it's tied to the Qt version. 
> Therefore, it fails the requirement for supporting everything the old version 
> supported. 

Well if you were using modules that are no longer supported, or you run into 
some little incompatibility; but we have been trying to avoid API breaks.  QML 
files that begin with “import QtQuick 2.0” still work fine so far; also 
Controls, Layouts etc.  So IMO it’s less onerous than the python upgrade.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development