[Development] moc output from non-local tool build

[Marius Kittler]

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.