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
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 th
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
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 i
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 - t
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 QtHe
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
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/"remo
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
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 yester
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 benefi
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.
> 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
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 el
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 tu
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 che
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 r
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 versio
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 Qt6
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 Yoct
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 conv
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 supp
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/brows
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 l
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)
> unti
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
f: 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
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 th
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
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
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 configurati
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
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 sl
46 matches
Mail list logo
