[Development] moc output from non-local tool build

Thiago Macieira thiago.macieira at intel.com
Wed Sep 15 02:25:24 CEST 2021


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





More information about the Development mailing list