Re: [Development] moc output from non-local tool build
On Tuesday, 16 November 2021 04:39:59 PST Marius Kittler wrote: > > Indeed. The proposal was how old that build can be. Can you count on the > > host Linux distribution being up-to-date enough to have N-1 or even N-3? > > Because you can't, then the point is moot. > > I am *not* worried about the host distribution being up-to-date enough. It > is actually quite the opposite. The normal distribution's host Qt build is > likely updated a little bit sooner than the cross-builds. On the other hand > I can easily postpone updating the cross-builds until the normal host > distribution's Qt build is updated. The delay for updating the cross-builds > won't be long, though. So if a host build can be used with a cross-build of > the previous Qt 6 release that's completely sufficient. Please note I was thinking of a "you" in the persona of a regular developer using the Linux distribution, not the persona of a Linux distribution packager. -- 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] moc output from non-local tool build
Am Mittwoch, 10. November 2021, 16:26:43 CET schrieb Thiago Macieira: > On Wednesday, 10 November 2021 03:29:15 PST Marius Kittler wrote: > > Am Dienstag, 9. November 2021, 19:59:29 CET schrieb Thiago Macieira: > > > On Friday, 5 November 2021 08:28:20 PST Scott Bloom wrote: > > > > Why wouldn’t they simply have two versions of Qt ( or more) the one > > > > they > > > > are targeting for desktop, and the previous one they are targeting for > > > > android/"remote" > > > > > > I don't mind that. If we enforce you must have a matching version of the > > > host tools, then we do it. > > > > > > Since I don't cross compile, people who do should speak up and explain > > > why > > > it would be too difficult for them to have a native build of the same > > > version of Qt they're going to cross-compile. > > > > > > Silence will mean consent. > > > > It would of course be possible to conduct a 2nd host build which would > > only > > be updated in accordance with the cross-builds. I suppose it would also be > > possible to strip this 2nd build down to "tools only" by specifying some > > CMake variables. It also needed to be installed within a different prefix > > to avoid conflicts with the normal host build. > > Please clarify what you meant by "2nd host build". Do mean "2nd build, which > is host" or did you really mean "another host build for a total of 3 > builds"? I assume it's the former. The distribution (in this case Arch Linux) already provides a full Qt build (none-cross). So far I'm relying on that build for additional cross-builds. However, due to the compatibility issue I might need to do a 3rd build. It would be the same as the Qt build by the distribution but only updated in accordance with the cross-builds to avoid the compatibility problem. And that build would preferably be striped down to only tools and their dependencies. > Considering tools aren't going to be bootstrapped any more, the host build > of the tools might be quite complete. It needs to include at least every > library that the tools depend on. So for example it will need to go all the > way to qttools to build QtHelp so qhelpgenerator may link to it. I don't > know if there's something that we can do in the CMake side to enable only > those targets by default, but the difference might actually be so small > that it's not worth maintaining. I suppose one could at least building most of the plugins, e.g. Qt Gui seems to be required by some of the tools but it looks like building the plugins could be avoided. > > However, it would certainly be more efficient and less packaging work to > > simply be able to reuse the normal host build which is already in the > > distribution. So it would just make packaging easier. > > Indeed. The proposal was how old that build can be. Can you count on the > host Linux distribution being up-to-date enough to have N-1 or even N-3? > Because you can't, then the point is moot. I am *not* worried about the host distribution being up-to-date enough. It is actually quite the opposite. The normal distribution's host Qt build is likely updated a little bit sooner than the cross-builds. On the other hand I can easily postpone updating the cross-builds until the normal host distribution's Qt build is updated. The delay for updating the cross-builds won't be long, though. So if a host build can be used with a cross-build of the previous Qt 6 release that's completely sufficient. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] moc output from non-local tool build
On 11/15/21 5:41 PM, Marius Kittler wrote: Am Montag, 15. November 2021, 16:46:31 CET schrieben Sie: On Monday, 15 November 2021 05:52:46 PST Joerg Bornemann wrote: There's already a target called host_tools to build the necessary tools. An install target/component for it is missing though, see QTBUG-91243. Which tools does it build and which libraries does that need? I suppose it needed to build *all* tools which might be called at some point during compilation including tools provided by further repositories like qttools and qtshadertools because this is not for bootstrapping-only but for having all the tools available Qt consists of when cross-compiling. That means likely also building all Qt the libraries these tools depend on (e.g. Qt Core, Gui and ShaderTools libraries for `qsb`). So in the end the build wouldn't be *that* minimal but it would still be better than having to build everything. Correct. The target "host_tools" is building all "tools" but not the "apps", i.e. all executables that are added with qt_internal_add_tool but not the executables that are added with qt_internal_add_app. All necessary dependencies, libraries and plugins are built too. Any module that is not used by any tool won't be built. YMMV whether the hassle is worth it dependending on use case and work-flow. Feedback is appreciated. As mentioned, a proper installation component is missing, but you can use a non-prefix build as "host only build". Cheers, Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] moc output from non-local tool build
Am Montag, 15. November 2021, 16:46:31 CET schrieben Sie: > On Monday, 15 November 2021 05:52:46 PST Joerg Bornemann wrote: > > There's already a target called host_tools to build the necessary tools. > > An install target/component for it is missing though, see QTBUG-91243. > > Which tools does it build and which libraries does that need? I suppose it needed to build *all* tools which might be called at some point during compilation including tools provided by further repositories like qttools and qtshadertools because this is not for bootstrapping-only but for having all the tools available Qt consists of when cross-compiling. That means likely also building all Qt the libraries these tools depend on (e.g. Qt Core, Gui and ShaderTools libraries for `qsb`). So in the end the build wouldn't be *that* minimal but it would still be better than having to build everything. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] moc output from non-local tool build
On Monday, 15 November 2021 05:52:46 PST Joerg Bornemann wrote: > There's already a target called host_tools to build the necessary tools. > An install target/component for it is missing though, see QTBUG-91243. Which tools does it build and which libraries does that need? -- 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] moc output from non-local tool build
On 11/10/21 4:26 PM, Thiago Macieira wrote: Considering tools aren't going to be bootstrapped any more, the host build of the tools might be quite complete. It needs to include at least every library that the tools depend on. So for example it will need to go all the way to qttools to build QtHelp so qhelpgenerator may link to it. I don't know if there's something that we can do in the CMake side to enable only those targets by default, but the difference might actually be so small that it's not worth maintaining. There's already a target called host_tools to build the necessary tools. An install target/component for it is missing though, see QTBUG-91243. BR, Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] moc output from non-local tool build
On Wednesday, 10 November 2021 03:29:15 PST Marius Kittler wrote: > Am Dienstag, 9. November 2021, 19:59:29 CET schrieb Thiago Macieira: > > On Friday, 5 November 2021 08:28:20 PST Scott Bloom wrote: > > > Why wouldn’t they simply have two versions of Qt ( or more) the one they > > > are targeting for desktop, and the previous one they are targeting for > > > android/"remote" > > > > I don't mind that. If we enforce you must have a matching version of the > > host tools, then we do it. > > > > Since I don't cross compile, people who do should speak up and explain why > > it would be too difficult for them to have a native build of the same > > version of Qt they're going to cross-compile. > > > > Silence will mean consent. > > It would of course be possible to conduct a 2nd host build which would only > be updated in accordance with the cross-builds. I suppose it would also be > possible to strip this 2nd build down to "tools only" by specifying some > CMake variables. It also needed to be installed within a different prefix > to avoid conflicts with the normal host build. Please clarify what you meant by "2nd host build". Do mean "2nd build, which is host" or did you really mean "another host build for a total of 3 builds"? I assume it's the former. Considering tools aren't going to be bootstrapped any more, the host build of the tools might be quite complete. It needs to include at least every library that the tools depend on. So for example it will need to go all the way to qttools to build QtHelp so qhelpgenerator may link to it. I don't know if there's something that we can do in the CMake side to enable only those targets by default, but the difference might actually be so small that it's not worth maintaining. > However, it would certainly be more efficient and less packaging work to > simply be able to reuse the normal host build which is already in the > distribution. So it would just make packaging easier. Indeed. The proposal was how old that build can be. Can you count on the host Linux distribution being up-to-date enough to have N-1 or even N-3? Because you can't, then the point is moot. -- 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] moc output from non-local tool build
Am Dienstag, 9. November 2021, 19:59:29 CET schrieb Thiago Macieira: > On Friday, 5 November 2021 08:28:20 PST Scott Bloom wrote: > > Why wouldn’t they simply have two versions of Qt ( or more) the one they > > are targeting for desktop, and the previous one they are targeting for > > android/"remote" > > I don't mind that. If we enforce you must have a matching version of the > host tools, then we do it. > > Since I don't cross compile, people who do should speak up and explain why > it would be too difficult for them to have a native build of the same > version of Qt they're going to cross-compile. > > Silence will mean consent. It would of course be possible to conduct a 2nd host build which would only be updated in accordance with the cross-builds. I suppose it would also be possible to strip this 2nd build down to "tools only" by specifying some CMake variables. It also needed to be installed within a different prefix to avoid conflicts with the normal host build. However, it would certainly be more efficient and less packaging work to simply be able to reuse the normal host build which is already in the distribution. So it would just make packaging easier. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] moc output from non-local tool build
On Friday, 5 November 2021 08:28:20 PST Scott Bloom wrote: > Why wouldn’t they simply have two versions of Qt ( or more) the one they are > targeting for desktop, and the previous one they are targeting for > android/"remote" I don't mind that. If we enforce you must have a matching version of the host tools, then we do it. Since I don't cross compile, people who do should speak up and explain why it would be too difficult for them to have a native build of the same version of Qt they're going to cross-compile. Silence will mean consent. -- 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] moc output from non-local tool build
On Thursday, 4 November 2021 09:46:56 PST Joerg Bornemann wrote: > As to the question "how we will inform the tools of what version we're > asking for": one way is to add -compat-version switches to the tools > that need them. The downside here is that this needs to be done the day > before yesterday for all tools that contribute to the build. That was what I had intended with https://codereview.qt-project.org/c/qt/qtbase/+/370996 > Another way would be to load it onto the user to set an environment > variable QT_TOOL_COMPAT_VERSION or such that is read by tools that need to. This is probably easier. -- 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] moc output from non-local tool build
Why wouldn’t they simply have two versions of Qt ( or more) the one they are targeting for desktop, and the previous one they are targeting for android/"remote" -Original Message- From: Development On Behalf Of Joerg Bornemann Sent: Friday, November 5, 2021 2:28 AM To: Volker Hilsheimer Cc: Macieira, Thiago ; development@qt-project.org Subject: Re: [Development] moc output from non-local tool build On 11/5/21 12:06 AM, Volker Hilsheimer wrote: > Does anyone other than developers of Qt (and for us this could be a real time > saver!) really need and benefit from this? I’d rather not want to ask our > support team to support customers and users with a colorful blend of moc and > library versions. This here describes a use case from a packager perspective: https://lists.qt-project.org/pipermail/development/2021-September/041746.html 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] moc output from non-local tool build
On 11/5/21 12:06 AM, Volker Hilsheimer wrote: Does anyone other than developers of Qt (and for us this could be a real time saver!) really need and benefit from this? I’d rather not want to ask our support team to support customers and users with a colorful blend of moc and library versions. This here describes a use case from a packager perspective: https://lists.qt-project.org/pipermail/development/2021-September/041746.html Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] moc output from non-local tool build
> On 4 Nov 2021, at 17:46, Joerg Bornemann wrote: > > On 10/29/21 11:43 AM, Joerg Bornemann wrote: > With https://codereview.qt-project.org/c/qt/qtbase/+/378053 it's now possible to turn off the package version check and to use moc of a different Qt version. This requires that moc stays either compatible or handles that /version argument outlined elsewhere in this thread. >>> >>> Which is great, and is what I want, but we still need a decision on how long >>> the compatibility window will be and how we will inform the tools of what >>> version we're asking for. >> A sliding window of two years has been proposed in this thread. Assuming two >> minor version bumps per year, that's four minor versions. Let's make that an >> odd number and we get the following >> Proposal 1: >> Qt 6.X should work with host tools of Qt 6.Y, where X-2 <= Y <= X+2 >> That's quite some commitment. >> How about >> Proposal 2: >> Qt 6.X should work with host tools of Qt 6.Y, where X-1 <= Y <= X+1 >> That gives us less to test, and the sliding window is something like 1.5 >> years. > > Any comments on the sliding window size? > > Apart from that, after internal discussion I have to lower expectations > regarding our commitment to this. I don't see us creating the test infra for > testing the build of different host/target Qt combinations. As such we offer > no commitment or support, but we will accept patches that improve the > situation > > As to the question "how we will inform the tools of what version we're asking > for": one way is to add -compat-version switches to the tools that need them. > The downside here is that this needs to be done the day before yesterday for > all tools that contribute to the build. > > Another way would be to load it onto the user to set an environment variable > QT_TOOL_COMPAT_VERSION or such that is read by tools that need to. Does anyone other than developers of Qt (and for us this could be a real time saver!) really need and benefit from this? I’d rather not want to ask our support team to support customers and users with a colorful blend of moc and library versions. If not, then supporting the moc from the latest released series to be able to work with dev seems to be sufficient, doesn’t it? If I can reliably use Qt 6.2’s moc to build dev, and don’t have to worry that an ever-so-light-touching of QtCore ends up with rebuilding a world of moc files, then that’d be a real win. Ditto for cross compilation. If you don’t work on Qt, then I’d assume that you have Qt host tools from a package installed for the versions you need anyway. And then it can be on a “best effort” level; there’ll be some surprises, just as there sometimes are surprises if your qtdeclarative test fails because you’re building against today’s qtbase, and if people that feel that pain fiercely enough come up with a test rig that catches such glitches during CI, then great. But it’s not exactly a blocker either. Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] moc output from non-local tool build
On 10/29/21 11:43 AM, Joerg Bornemann wrote: With https://codereview.qt-project.org/c/qt/qtbase/+/378053 it's now possible to turn off the package version check and to use moc of a different Qt version. This requires that moc stays either compatible or handles that /version argument outlined elsewhere in this thread. Which is great, and is what I want, but we still need a decision on how long the compatibility window will be and how we will inform the tools of what version we're asking for. A sliding window of two years has been proposed in this thread. Assuming two minor version bumps per year, that's four minor versions. Let's make that an odd number and we get the following Proposal 1: Qt 6.X should work with host tools of Qt 6.Y, where X-2 <= Y <= X+2 That's quite some commitment. How about Proposal 2: Qt 6.X should work with host tools of Qt 6.Y, where X-1 <= Y <= X+1 That gives us less to test, and the sliding window is something like 1.5 years. Any comments on the sliding window size? Apart from that, after internal discussion I have to lower expectations regarding our commitment to this. I don't see us creating the test infra for testing the build of different host/target Qt combinations. As such we offer no commitment or support, but we will accept patches that improve the situation As to the question "how we will inform the tools of what version we're asking for": one way is to add -compat-version switches to the tools that need them. The downside here is that this needs to be done the day before yesterday for all tools that contribute to the build. Another way would be to load it onto the user to set an environment variable QT_TOOL_COMPAT_VERSION or such that is read by tools that need to. BR, Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] moc output from non-local tool build
On 10/28/21 5:52 PM, Thiago Macieira wrote: On Wednesday, 27 October 2021 23:02:38 PDT Joerg Bornemann wrote: a problem, I just want to know if this is required. ping for decision prior to 6.3 feature freeze. With https://codereview.qt-project.org/c/qt/qtbase/+/378053 it's now possible to turn off the package version check and to use moc of a different Qt version. This requires that moc stays either compatible or handles that /version argument outlined elsewhere in this thread. Which is great, and is what I want, but we still need a decision on how long the compatibility window will be and how we will inform the tools of what version we're asking for. A sliding window of two years has been proposed in this thread. Assuming two minor version bumps per year, that's four minor versions. Let's make that an odd number and we get the following Proposal 1: Qt 6.X should work with host tools of Qt 6.Y, where X-2 <= Y <= X+2 That's quite some commitment. How about Proposal 2: Qt 6.X should work with host tools of Qt 6.Y, where X-1 <= Y <= X+1 That gives us less to test, and the sliding window is something like 1.5 years. Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] moc output from non-local tool build
On 10/27/21 7:18 PM, Thiago Macieira wrote: On Friday, 10 September 2021 07:58:55 PDT Thiago Macieira wrote: Qt 6 supports using the moc from a different build of Qt, to help with the bootstrapping issue and also so you don't always run a debug-mode moc in your debug builds of Qt. Is that moc required to be from the same Qt version as the Qt you're trying to build? Or is there a leeway in accepting slightly different builds? We haven't yet made changes to the moc output that would make it incompatible, but I am thinking of doing that now for plugins and I'd like to know if I have to keep compatibility with a slightly older moc. It's not a problem, I just want to know if this is required. ping for decision prior to 6.3 feature freeze. With https://codereview.qt-project.org/c/qt/qtbase/+/378053 it's now possible to turn off the package version check and to use moc of a different Qt version. This requires that moc stays either compatible or handles that /version argument outlined elsewhere in this thread. Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] moc output from non-local tool build
On Friday, 10 September 2021 07:58:55 PDT Thiago Macieira wrote: > Qt 6 supports using the moc from a different build of Qt, to help with the > bootstrapping issue and also so you don't always run a debug-mode moc in > your debug builds of Qt. > > Is that moc required to be from the same Qt version as the Qt you're trying > to build? Or is there a leeway in accepting slightly different builds? > > We haven't yet made changes to the moc output that would make it > incompatible, but I am thinking of doing that now for plugins and I'd like > to know if I have to keep compatibility with a slightly older moc. It's not > a problem, I just want to know if this is required. ping for decision prior to 6.3 feature freeze. -- 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] moc output from non-local tool build
On 9/14/21 9:08 PM, 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. Doesn't work with non-qtbase repos though. And this is, because Qt6Foo depends on Qt6FooTools such that in a cross-build, find_package(Qt6Core) will trigger find_package(Qt6CoreTools). The latter will be found in the host Qt. The target Qt does not provide Qt6FooTools packages. Changing this is a deep intrusion in the mechanics of cross builds, which we don't see the need to do right now. Instead, we'll address the use case of mixing different versions of host Qt and target Qt by adding a switch to turn off any version check. See discussion at QTBUG-96458. Cheers, Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] moc output from non-local tool build
On Monday, 20 September 2021 01:33:04 PDT Joerg Bornemann wrote: > On 9/15/21 5:21 AM, Thiago Macieira wrote: > > On Tuesday, 14 September 2021 09:03:59 PDT Joerg Bornemann wrote: > >> Unless QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is ON which is used in yocto > >> context. > > > > I don't see why Yocto Project recipes need to be special. > > They don't need to be special, it's just convenient to have the tools on > the target too. Sure, but that's now the default in Qt 6. With Qt 4-5, it was a mess to get the tools on target because in a cross-compilation, they'd always be host builds. -- 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] moc output from non-local tool build
On 9/15/21 5:21 AM, Thiago Macieira wrote: On Tuesday, 14 September 2021 09:03:59 PDT Joerg Bornemann wrote: Unless QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is ON which is used in yocto context. I don't see why Yocto Project recipes need to be special. They don't need to be special, it's just convenient to have the tools on the target too. My problem as a QtCore developer is that almost anything I do will cause the Bootstrap lib to rebuild, then moc gets relinked, then header and source with Q_OBJECT is re-moc'ed and recompiled. Yeah that's QTBUG-92269. This affects especially QtCore developers. :-/ When your change to use the pre-built tools is in, the problem lessens, in that the moc that is used won't change, so I won't get everything re-moc'ed and recompiled. However, the Bootstrap lib still gets recompiled and moc relinked, so it's unnecessary work. I'd like to start depopulating the Bootstrap lib so it's MUCH smaller: it should only have what moc and tracegen need. You can do that, with https://codereview.qt-project.org/c/qt/qtbase/+/370954 these are the only bootstrapped tools left: moc, tracegen and cmake_automoc_parser (which I forgot the last time we talked about this). BR, Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] moc output from non-local tool build
On 9/14/21 4:35 PM, Thiago Macieira wrote: FWIW, in multi-config builds, with a recent enough CMake version, tools are built in release config only. $ cmake --version cmake version 3.21.2 CMake suite maintained and supported by Kitware (kitware.com/cmake). Should I upgrade? No, that's supposed to be fine. QTBUG-95803 gets in the way of your workflow though. BR, Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] moc output from non-local tool build
On Tuesday, 14 September 2021 00:46:10 PDT Joerg Bornemann wrote: > Not sure what you're getting at here. Ninja multi-config and > QT_HOST_PATH are orthogonal features. Have these implementation issues > been reported? Yes. https://bugreports.qt.io/browse/QTBUG-95803 https://bugreports.qt.io/browse/QTBUG-96451 https://bugreports.qt.io/browse/QTBUG-95099 Plus an unreported but mentioned one that none of the tests that use auxiliary builds such as plugins and helper executables can find their helper tools. Just try to run tst_qprocess or any corelib/plugin test. > FWIW, in multi-config builds, with a recent enough CMake version, tools > are built in release config only. $ cmake --version cmake version 3.21.2 CMake suite maintained and supported by Kitware (kitware.com/cmake). Should I upgrade? -- 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] moc output from non-local tool build
On Tuesday, 14 September 2021 09:03:59 PDT Joerg Bornemann wrote: > Unless QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is ON which is used in yocto > context. I don't see why Yocto Project recipes need to be special. My problem as a QtCore developer is that almost anything I do will cause the Bootstrap lib to rebuild, then moc gets relinked, then header and source with Q_OBJECT is re-moc'ed and recompiled. When your change to use the pre-built tools is in, the problem lessens, in that the moc that is used won't change, so I won't get everything re-moc'ed and recompiled. However, the Bootstrap lib still gets recompiled and moc relinked, so it's unnecessary work. I'd like to start depopulating the Bootstrap lib so it's MUCH smaller: it should only have what moc and tracegen need. -- 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] moc output from non-local tool build
On Wednesday, 15 September 2021 02:39:18 PDT Edward Welbourne wrote: > As a third alternative, we could introduce an environment variable that > can be over-ridden by command-line options; then in the early stages the > build system uses the environment variable (for backwards compatibility) > until we're far enough past the introduction of the command-line option > that the sliding window now allows us to use them in the build system. > A few versions after that we can drop the environment variable support, > if we feel any need to do so. Yes, that works 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] 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 that route. Not unless we make one, by policy. I think we should. I propose we limit compatibility to ±3 minor releases. For example, that means Qt 6.3 should build with the tools from Qt 6.0 through 6.6. Effectively: A) library code that consumes tool output must be compatible with the output generated from the previous 3 versions B) tools must retain the ability to produce content limited that is accepted by any of the previous 3 versions C) all tools should get a command-line flag to specify the requested output version ASAP Since these options don't exist yet: D) the buildsystems (both CMake and qmake) should be updated to pass starting the command-line option with Qt 6.5 (if we get them in 6.2.0) or 6.6 (if not) E) until then, the tool output and the header consumption must remain compatible forwards and backwards. Only in the N+1 release (6.6 or 6.7) will we be allowed to change the default output. That means change https://codereview.qt-project.org/c/qt/qtbase/+/370750/1 needs to retain compatibility without a flag (easy for me). Questions: a) should we reduce to ±2 minor releases? ±3 is the 2-year sliding window and ensures there are two LTS in the range (not counting the release itself, if it is an LTS), whereas ±2 means there's only one and an LTS is not required to be compatible with any other. b) can we get the version flags right now, in 6.2.0? The tools don't need to do anything with the flag, only accept it. c) alternatively, should we use an environment variable? That way, the buildsystems don't have to wait for 6.5/6.6 to start setting them, which means we can change the defaults at those versions, instead of N+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] 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 backward if I read your requirements correctly. Why? The host build's cmake files should not at all be used or influence how they're used. All we need is the path to the tools, which are all in the libexec of that build. You got a point there. This needs more investigation, but I think QTBUG-85084 is related. 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 that route. Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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. Why? The host build's cmake files should not at all be used or influence how they're used. All we need is the path to the tools, which are all in the libexec of that build. You got a point there. This needs more investigation, but I think QTBUG-85084 is related. Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 used in QtCore. I forgot about it. rcc isn't used for QtCore any more. Good point. Let's unbootstrap it: https://codereview.qt-project.org/c/qt/qtbase/+/370954 I have a hunch we're talking about different things here. A moc-only, or even a qtbase-only build won't get you far when trying to cross-compile qtdeclarative or such. Ok, so to clarify: All builds should bootstrap only the tools that are needed to compile QtCore. The other tools should link to QtCore, not to the bootstrap lib. Yes. A cross-compiling build needs to use a host tool set, for all tools, because all tools it builds are for the target and therefore can't be run in the host system. Yes. Unless QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is ON which is used in yocto context. Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 isn't used for QtCore any more. > I have a hunch we're talking about different things here. A moc-only, or > even a qtbase-only build won't get you far when trying to cross-compile > qtdeclarative or such. Ok, so to clarify: All builds should bootstrap only the tools that are needed to compile QtCore. The other tools should link to QtCore, not to the bootstrap lib. A cross-compiling build needs to use a host tool set, for all tools, because all tools it builds are for the target and therefore can't be run in the host system. -- 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] 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 requested before (QTBUG-91243) and is likely the most feasible option for Marius' request. I oppose that in the grounds of your previous paragraph. 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. I have a hunch we're talking about different things here. A moc-only, or even a qtbase-only build won't get you far when trying to cross-compile qtdeclarative or such. Cheers, Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 should not at all be used or influence how they're used. All we need is the path to the tools, which are all in the libexec of that build. If it's too difficult, just use qtpaths or pkg-config. -- 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] 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 likely the most feasible option for Marius' request. I oppose that in the grounds of your previous paragraph. Only moc should link to the Bootstrap lib. Period. -- 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] 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 correctly. I'm afraid that's the next challenge, indeed. I've recently tried to use host Qt 6.2 (beta) with Qt 6.1.3 targeting mingw-w64 and it also broke because it couldn't find some CMake functions. One would have expected that this isn't a problem because my host Qt was newer but apparently its configuration files are not self-contained and try to call helper functions from the target Qt instead of "staying in the host world". But would be "staying in the host world" problematic? I suppose it comes with the challenge of avoiding name clashes between the host and target worlds but I guess it should be doable. I think what you're seeing is the missing function __qt_internal_promote_target_to_global in that case. That function is used in exports (the host Qt) and in the actual build too (target Qt). The "right solution" probably would be a completely separated API for exports such that imported Qt packages can stay in their world. A pragmatic makeshift solution could be to backport such functions, maybe as empty stubs, once such failures are identified. And of course, we need some kind of test coverage or things are bound to regress. Cheers, Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 challenge, indeed. I've recently tried to use host Qt 6.2 (beta) with Qt 6.1.3 targeting mingw-w64 and it also broke because it couldn't find some CMake functions. One would have expected that this isn't a problem because my host Qt was newer but apparently its configuration files are not self-contained and try to call helper functions from the target Qt instead of "staying in the host world". But would be "staying in the host world" problematic? I suppose it comes with the challenge of avoiding name clashes between the host and target worlds but I guess it should be doable. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 two >> things missing: >> - a confirmation from Jörg that the current hard dependency on the >> exact version can be avoided, >> else the whole thing becomes moot. Given the fact that we cmake >> has support for version ranges >> that should however be trivial, as long as we actually preserve >> compatibility (and accept the > > resulting maintenance burden). > > The version check can be conditionally dropped. > Or, we can maybe figure out the version of host Qt and use that. > > 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. > If we intend to do this, could we please also discuss how to best add some support for it on the CI to prevent regressions on this feature. In the end this needs to be supported for all tools generating some sort of code, e.g. repc or uic. Dominik ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 much better to me. That's technically just a qtbase build. moc is the only tool that needs to bootstrap in a host build, all the rest link to QtCore. 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 likely the most feasible option for Marius' request. Cheers, Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 current hard dependency on the exact version can be avoided, else the whole thing becomes moot. Given the fact that we cmake has support for version ranges that should however be trivial, as long as we actually preserve compatibility (and accept the >resulting maintenance burden). The version check can be conditionally dropped. Or, we can maybe figure out the version of host Qt and use that. 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. Cheers, Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 "Qt6CoreTools" that is compatible with requested version "6.2.0". This is because our find_package calls for the host Qt contain the exact version number of the Qt that is being built. Fair enough, but then the question is whether that's intended or a simple accident of how it was implementation. I understand this version restriction as safety net that is supposed to prevent pulling in incompatible Qt packages. If we drop it entirely, it's even possible to pull in tools from different Qt builds that are pointed to by CMAKE_PREFIX_PATH. Maybe Alexandru can shed more light on this when he's back. And I just realize that the version restriction only works in one direction. It's possible to use Qt 6.2 as host Qt for 6.1 (if we ignore failures due to the incompatible internal API). BTW, is the functionality now working for non-crossing builds? It's been implemented with cross-builds as ultimate goal, but it's been used for documentation-only builds as well: https://wiki.qt.io/Qt_Build_System_Glossary#Documentation-only_Build I've been trying to use the CMake Ninja multi-config setup, but it's very painful due to lots of implementations issues. > I'll have to go back to regular single-config > and I don't want to use the local moc. Not sure what you're getting at here. Ninja multi-config and QT_HOST_PATH are orthogonal features. Have these implementation issues been reported? FWIW, in multi-config builds, with a recent enough CMake version, tools are built in release config only. Cheers, Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 can be avoided, else the whole thing becomes moot. Given the fact that we cmake has support for version ranges that should however be trivial, as long as we actually preserve compatibility (and accept the resulting maintenance burden). - some formal decision on how long that sliding window should be. 2 years sounds fine to me, but it might be better to express this in terms of Qt minor releases. -- Fabian Kosmale Software Engineer The Qt Company GmbH Erich-Thilo-Str. 10 D-12489 Berlin fabian.kosm...@qt.io +49 1638686070 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Von: Development im Auftrag von Thiago Macieira Gesendet: Montag, 13. September 2021 22:13 An: development@qt-project.org Betreff: Re: [Development] moc output from non-local tool build On Monday, 13 September 2021 11:21:37 PDT Thiago Macieira wrote: > Your way is easier on the packagers, though, since the cross-compilations > are usually not critical content, but the host/native Qt is. But I don't > think it's the typical scenario for cross-compiling. People usually > download the sources in order to cross-compile Qt with their device's > toolchain and they'd like to use the system's Qt to help bootstrap. The > system's Qt is usually older. Ah, but for embedded device targets, one usually wants the best possible, so depending on your distro's older and crappier moc is not a good idea. Sounds to me like we should do both, with a 2-year sliding window of compatibility. My current changes require no extra effort (they're done anyway, will push soon). Adding the version arguments to the tools requires a bit more effort. -- 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] moc output from non-local tool build
On Monday, 13 September 2021 11:21:37 PDT Thiago Macieira wrote: > Your way is easier on the packagers, though, since the cross-compilations > are usually not critical content, but the host/native Qt is. But I don't > think it's the typical scenario for cross-compiling. People usually > download the sources in order to cross-compile Qt with their device's > toolchain and they'd like to use the system's Qt to help bootstrap. The > system's Qt is usually older. Ah, but for embedded device targets, one usually wants the best possible, so depending on your distro's older and crappier moc is not a good idea. Sounds to me like we should do both, with a 2-year sliding window of compatibility. My current changes require no extra effort (they're done anyway, will push soon). Adding the version arguments to the tools requires a bit more effort. -- 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] moc output from non-local tool build
On Monday, 13 September 2021 09:13:02 PDT Marius Kittler wrote:
> From my GNU/Linux user/distributor perspective it would be great if the host
> moc could be slightly newer than the target Qt libs. So if the distribution
> upgrades the regular Qt package the cross packages (targeting mingw-w64 and
> Android) would still be usable until they're updated as well. I don't
> expect that there would be a big delay. So it would be sufficient if moc
> would be able to generate files which can still be used with the previous
> release of Qt, so moc from Qt 6.2.0 would be able to generate files for Qt
> 6.1.3 libraries.
I was thinking the opposite: that the moc tool could be slightly older. Qt
already needs to deal with compiled moc content that hasn't been recompiled,
so the libraries already have backwards-compatibility in one direction. If
there was a need to have extra compatibility, I thought extending QtCore
compatibility with moc content that hasn't been regenerated would be the
logical next step.
Doing your way is possible, but probably requires that moc output #ifdef
content. Whereas my change would replace:
QT_PLUGIN_METADATA_SECTION
static constexpr unsigned char qt_pluginMetaData_QEglFSIntegrationPlugin[] = {
'Q', 'T', 'M', 'E', 'T', 'A', 'D', 'A', 'T', 'A', ' ', '!',
// metadata version, Qt version, architectural requirements
0, QT_VERSION_MAJOR, QT_VERSION_MINOR, qPluginArchRequirements(),
[...some content..]
};
QT_MOC_EXPORT_PLUGIN(QEglFSIntegrationPlugin, QEglFSIntegrationPlugin)
with
static constexpr unsigned char qt_pluginMetaDataV2_QEglFSIntegrationPlugin[] =
{
[... same content ...]
};
QT_MOC_EXPORT_PLUGIN_V2(QEglFSIntegrationPlugin, QEglFSIntegrationPlugin,
qt_pluginMetaDataV2_QEglFSIntegrationPlugin)
Your way is easier on the packagers, though, since the cross-compilations are
usually not critical content, but the host/native Qt is. But I don't think
it's the typical scenario for cross-compiling. People usually download the
sources in order to cross-compile Qt with their device's toolchain and they'd
like to use the system's Qt to help bootstrap. The system's Qt is usually
older.
> To me it would make sense adding a CLI flag to moc to specify the target
> version and the CMake build scripts would pass it automatically (instead of
> rejecting the newer moc completely like it is currently implemented).
That works too. It's doable for moc to remember how to emit old code, so a
version switch would help it. By default, it would simply emit "latest".
> Of course all of this effort would be quite fruitless if other tools like
> uic would not support the same as well. Likely those tools are quite
> unproblematic. Maybe only the build system needs to be changed to accept
> newer host versions.
True, but those tools change much less frequently and integrate much less
tightly than moc.
If we decide to go this route, we should add the version flag right now, even
if we don't use it. That way, if a new version wants to use it, an older build
will have passed it.
> 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 much better to me.
That's technically just a qtbase build. moc is the only tool that needs to
bootstrap in a host build, all the rest link to QtCore.
Which reminds me we can probably shrink the bootstrap lib to bare bones and
save on compilation time.
--
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] moc output from non-local tool build
Am Freitag, 10. September 2021, 16:58:55 CEST schrieb Thiago Macieira: > Qt 6 supports using the moc from a different build of Qt, to help with the > bootstrapping issue and also so you don't always run a debug-mode moc in > your debug builds of Qt. > > Is that moc required to be from the same Qt version as the Qt you're trying > to build? Or is there a leeway in accepting slightly different builds? > > We haven't yet made changes to the moc output that would make it > incompatible, but I am thinking of doing that now for plugins and I'd like > to know if I have to keep compatibility with a slightly older moc. It's not > a problem, I just want to know if this is required. From my GNU/Linux user/distributor perspective it would be great if the host moc could be slightly newer than the target Qt libs. So if the distribution upgrades the regular Qt package the cross packages (targeting mingw-w64 and Android) would still be usable until they're updated as well. I don't expect that there would be a big delay. So it would be sufficient if moc would be able to generate files which can still be used with the previous release of Qt, so moc from Qt 6.2.0 would be able to generate files for Qt 6.1.3 libraries. To me it would make sense adding a CLI flag to moc to specify the target version and the CMake build scripts would pass it automatically (instead of rejecting the newer moc completely like it is currently implemented). Of course all of this effort would be quite fruitless if other tools like uic would not support the same as well. Likely those tools are quite unproblematic. Maybe only the build system needs to be changed to accept newer host versions. 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 much better to me. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] moc output from non-local tool build
On Monday, 13 September 2021 00:38:55 PDT Joerg Bornemann 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 "Qt6CoreTools" that is >compatible with requested version "6.2.0". > > This is because our find_package calls for the host Qt contain the exact > version number of the Qt that is being built. Fair enough, but then the question is whether that's intended or a simple accident of how it was implementation. BTW, is the functionality now working for non-crossing builds? I've been trying to use the CMake Ninja multi-config setup, but it's very painful due to lots of implementations issues. I'll have to go back to regular single-config and I don't want to use the local moc. -- 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] moc output from non-local tool build
On 9/10/21 4:58 PM, Thiago Macieira wrote: Qt 6 supports using the moc from a different build of Qt, to help with the bootstrapping issue and also so you don't always run a debug-mode moc in your debug builds of Qt. Is that moc required to be from the same Qt version as the Qt you're trying to build? Or is there a leeway in accepting slightly different builds? 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 "Qt6CoreTools" that is compatible with requested version "6.2.0". This is because our find_package calls for the host Qt contain the exact version number of the Qt that is being built. Cheers, Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] moc output from non-local tool build
Qt 6 supports using the moc from a different build of Qt, to help with the bootstrapping issue and also so you don't always run a debug-mode moc in your debug builds of Qt. Is that moc required to be from the same Qt version as the Qt you're trying to build? Or is there a leeway in accepting slightly different builds? We haven't yet made changes to the moc output that would make it incompatible, but I am thinking of doing that now for plugins and I'd like to know if I have to keep compatibility with a slightly older moc. It's not a problem, I just want to know if this is required. -- 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
