[Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Konstantin Tokarev]

31.05.2019, 00:57, "Thiago Macieira" <thiago.macieira at intel.com>:
> On Thursday, 30 May 2019 14:34:52 PDT Konstantin Tokarev wrote:
>>  > 3) all tools in cross builds link to a host QtCore that must be
>>  > preinstalled Preferably, reuse the tools from that host build instead of
>>  > building again
>>  The latter item implies that there should be some compatibility gurantees
>>  allowing to use tools from Qt 6.x when building Qt 6.y, otherwise it will
>>  be really inconvenient
>
> I understand, but aside from qmake, I don't know of any build system that
> allows for building both host and target in the same build. That means
> whatever we use in Qt 6, we'll a separate build for host tools when cross-
> compiling.

That's not exactly correct, as any build system which supports custom build rules
(or "custom compilers" in qmake parlance) can implement such bootstrap without
much pain. Most of build systems around, starting from good old make, support
custom build rules [1]. Unfortunately, cmake is less expressive than make, as it
supports [2] only custom targets ()

Fortunately, cmake has ExternalProject feature which can be used to work around
this limitation. Cross build can build moc as a separate cmake project with host
toolchain, and use it.

[1] IIRC Premake 5.x featured explicit support for using different toolchains for different
target in the same project

[2] Besides a few built-in "first class" languages, implemented in c++ core

[3] Yet I've seen people using cycles + add_custom_target() to compile source code
with a compiler built in the same cmake project

>
> I don't see a problem in requiring the same version in the host and the target
> being built. But if this is not possible, then we'll need to have an extra
> step when preparing for cross-builds that bootstraps the host tools.

ExternalProject to the rescue.

-- 
Regards,
Konstantin