Re: [Development] moc output from non-local tool build

On Tuesday, 14 September 2021 12:08:20 PDT Joerg Bornemann wrote: > I've experimented with this and came up with > https://codereview.qt-project.org/c/qt/qtbase/+/370958 > which allows to build qtbase dev (6.3.0) against a host Qt 6.1.2. > > Note that we don't have any version restriction if we go

Re: [Development] moc output from non-local tool build

On 9/14/21 6:10 PM, Joerg Bornemann wrote: On 9/14/21 4:29 PM, Thiago Macieira wrote: On Tuesday, 14 September 2021 00:51:21 PDT Joerg Bornemann wrote: The maintenance burden is next level. This would mean to keep all internal API that's used in lib/cmake compatible. Apparently forward and back

Re: [Development] Qbs development

Thanks for the response. I can provide a third option - we can move Qbs out of the Qt Governance Model by moving to GitHub. I have raised this topic on our Discord server and the community overall seems positive - there were several votes for the migration and no votes against. This migration mi

Re: [Development] moc output from non-local tool build

On 9/14/21 4:29 PM, Thiago Macieira wrote: On Tuesday, 14 September 2021 00:51:21 PDT Joerg Bornemann wrote: The maintenance burden is next level. This would mean to keep all internal API that's used in lib/cmake compatible. Apparently forward and backward if I read your requirements correctly.

Re: [Development] moc output from non-local tool build

On 9/14/21 5:45 PM, Thiago Macieira wrote: On Tuesday, 14 September 2021 08:37:55 PDT Joerg Bornemann wrote: Only moc should link to the Bootstrap lib. Period. Well, I guess rcc could also use some good pinch of bootstrapping. And tracegen for that matter. Well, tracegen might, since it's us

Re: [Development] moc output from non-local tool build

On Tuesday, 14 September 2021 08:37:55 PDT Joerg Bornemann wrote: > > Only moc should link to the Bootstrap lib. Period. > > Well, I guess rcc could also use some good pinch of bootstrapping. > And tracegen for that matter. Well, tracegen might, since it's used in QtCore. I forgot about it. rcc

Re: [Development] moc output from non-local tool build

On 9/14/21 4:30 PM, Thiago Macieira wrote: On Tuesday, 14 September 2021 00:56:08 PDT Joerg Bornemann wrote: No it's not. There are more tools in other repos that are used in a cross-build. Bootstrapped or not does barely matter for cross-building. A proper host-tools-only build has been reques

Re: [Development] moc output from non-local tool build

On Tuesday, 14 September 2021 00:51:21 PDT Joerg Bornemann wrote: > The maintenance burden is next level. This would mean to keep all > internal API that's used in lib/cmake compatible. Apparently forward and > backward if I read your requirements correctly. Why? The host build's cmake files shoul

Re: [Development] moc output from non-local tool build

On Tuesday, 14 September 2021 00:56:08 PDT Joerg Bornemann wrote: > No it's not. There are more tools in other repos that are used in a > cross-build. Bootstrapped or not does barely matter for cross-building. > > A proper host-tools-only build has been requested before (QTBUG-91243) > and is like

Re: [Development] Qbs development

Hi, Let’s also take up the formal part of the request. On 13 Sep 2021, at 22:59, Иван Комиссаров mailto:abba...@gmail.com>> wrote: Also, some actions might be taken to prevent from happening in the future - if technically possible, I’d like to request the revoke of his approver rights on the Q

Re: [Development] Qbs development

> On 14 Sep 2021, at 12:34, Richard Weickelt wrote: > > >> Just for the sake of clarity, who *is* the Maintainer of QBS ? >> Our wiki's [[Maintainers]] page only mentions Christian Kandeler as >> maintainer of Qt Creator's integration with it. I gather Ivan is a/the >> principal developer of QB

Re: [Development] Feature freeze exception for QTBUG-95587

I am wondering if the change was a good idea at all then. To me, it feels like the change at the root of all this was not well thought out. If it is expected that this change is going to hit so many users and they need some facility to make it easier on them than littering their code with Qt.re

Re: [Development] Feature freeze exception for QTBUG-95587

On 2021 Sep 13, at 20:58, Elvis Stansvik mailto:elvst...@gmail.com>> wrote: >> Yes, URLs are vital to QML I guess, but are they *that* vital? The >> bar should be quite high IMO. In the apps I've worked on, URLs and >> URL handling is really not central at all. IIUC, the present work has to do wi

Re: [Development] moc output from non-local tool build

On 9/14/21 12:11 PM, Marius Kittler wrote: Am Dienstag, 14. September 2021, 09:51:21 CEST schrieb Joerg Bornemann: The maintenance burden is next level. This would mean to keep all internal API that's used in lib/cmake compatible. Apparently forward and backward if I read your requirements corre

Re: [Development] Qbs development

> Just for the sake of clarity, who *is* the Maintainer of QBS ? > Our wiki's [[Maintainers]] page only mentions Christian Kandeler as > maintainer of Qt Creator's integration with it. I gather Ivan is a/the > principal developer of QBS in practice. Is Ossi co-Maintainer, or are > you really tal

Re: [Development] Feature freeze exception for QTBUG-95587

Hi, On 14-09-2021 09:12, Shawn Rutledge wrote: On 2021 Sep 13, at 20:58, Elvis Stansvik > wrote: Yes, URLs are vital to QML I guess, but are they *that* vital? The bar should be quite high IMO. In the apps I've worked on, URLs and URL handling is really not central

Re: [Development] moc output from non-local tool build

Am Dienstag, 14. September 2021, 09:51:21 CEST schrieb Joerg Bornemann: > The maintenance burden is next level. This would mean to keep all > internal API that's used in lib/cmake compatible. Apparently forward and > backward if I read your requirements correctly. > I'm afraid that's the next cha

Re: [Development] Qbs development

Jason McDonald (14 September 2021 08:04) replied: > I must refrain from commenting on the specific code review that is in > dispute, as I'm not familiar with that module, but I would like to > offer some more general remarks that I hope both you and Oswald will > find helpful. Likewise - and thank

Re: [Development] Qbs development

Hi, Not taking a stand to this particular issue, we in general are sometimes not very good in taking incremental steps. If some review becomes very long, taking months to complete, it rarely is the best way to tackle the issue. It can be better to split to multiple smaller items and progress th

Re: [Development] moc output from non-local tool build

Am 9/14/21 um 9:51 AM schrieb Joerg Bornemann: > On 9/14/21 9:25 AM, Fabian Kosmale wrote: >> I wouldn't mind adding/helping with adding/reviewing the necessary >> code to moc so that it has that >> compatibility support. I can certainly see the use case for it. >> However, I think there are still

Re: [Development] moc output from non-local tool build

On 9/13/21 8:21 PM, Thiago Macieira wrote: Alternatively it would also be interesting to provide a "tools only" build to be able to provide host tools of the required version. However, I actually like not having to build tools over and over again for every target so a "compatible" moc sounds muc

Re: [Development] moc output from non-local tool build

On 9/14/21 9:25 AM, Fabian Kosmale wrote: I wouldn't mind adding/helping with adding/reviewing the necessary code to moc so that it has that compatibility support. I can certainly see the use case for it. However, I think there are still two things missing: - a confirmation from Jörg that the c

Re: [Development] moc output from non-local tool build

On 9/13/21 5:30 PM, Thiago Macieira wrote: For a cross-build, currently, the host Qt needs to have the same version as the target Qt. When trying to build, let's say, Qt for Android 6.2.0 with a host Qt 6.1.2, you're getting an error: Could not find a configuration file for package "Qt6Core

Re: [Development] moc output from non-local tool build

I wouldn't mind adding/helping with adding/reviewing the necessary code to moc so that it has that compatibility support. I can certainly see the use case for it. However, I think there are still two things missing: - a confirmation from Jörg that the current hard dependency on the exact version

Re: [Development] Feature freeze exception for QTBUG-95587

On 2021 Sep 13, at 20:58, Elvis Stansvik mailto:elvst...@gmail.com>> wrote: Yes, URLs are vital to QML I guess, but are they *that* vital? The bar should be quite high IMO. In the apps I've worked on, URLs and URL handling is really not central at all. We’re talking about potentially a lot of I