nt 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. C
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
> -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
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
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
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
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
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,
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
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
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
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
> 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
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
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
>
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
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
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
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
> 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 Bornem
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
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
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
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
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
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
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
> 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
> 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
> -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
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
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
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
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
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.
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
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: [Dev
> -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:2
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
> -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
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.
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
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
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
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
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
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
> -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 K
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:
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
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
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
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.
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).
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
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.
> 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
>
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
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
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
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
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:
>
>
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
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.
>
>
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
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
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/
*
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> >>
> -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
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
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.
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
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
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
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
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)
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
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
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
> >
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
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
> 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
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
> 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
1 - 100 of 119 matches
Mail list logo
