[Development] CMake UNITY_BUILD ( QTBUG-109394 )

Friedemann Kleint Friedemann.Kleint at qt.io
Mon Jan 16 13:49:23 CET 2023


Hi,

I would like to propose considering making Qt suitable for CMake 
UNITY_BUILDs ( https://bugreports.qt.io/browse/QTBUG-109394 , 
https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html ) .

This has originally been proposed for Qt for Python  ( 
https://bugreports.qt.io/browse/PYSIDE-2155 ). It has greatly benefited 
from it; builds are much faster; particuarly for us in home-office where 
no distributed build environment exists.

It is basically what webengine has been using for a long time: Source 
files are concatenated to jumbo files which are then compiled.

For Qt for Python with its lots of generated files, the speed-up is 
drastic (~10x); for an average module (qttools), less so, but still:

Initial build of qttools:

Standard (675 files): real 3m26,016s / user 19m4,352s / sys 1m48,346s
Unity (203 files)   : real 2m2,557s  / user 9m40,147s / sys 0m47,144s 
(CMAKE_UNITY_BUILD_BATCH_SIZE=16)

with CCACHE/warmed up:

Standard (675 files): real 1m50,605s / user 8m9,512s  / sys 1m9,187s
Unity (203 files)   : real 1m30,990s / user 5m11,773s / sys 0m39,687s

Increasing CMAKE_UNITY_BUILD_BATCH_SIZE might also give better results.

Some modifications of the source code are required, though. The majority 
is actually improvements; things like missing header guards and macro 
re-definitions immediately show up; also Q_DECLARE_METATYPE() can be 
removed (see 
https://lists.qt-project.org/pipermail/development/2022-July/042744.html ).

But there is also a part that is more questionable; static functions 
need to be disambiguated; "using namespace" can cause clashes; class 
member fields from anonymous namespaces cause errors ( 
-Werror=subobject-linkage producing qerrormessage.cpp:38:7: error: 
‘QErrorMessagePrivate’ has a field ‘QErrorMessagePrivate::pending’ whose 
type uses the anonymous namespace ) and similar.

Some things are not fixable; exclusions can be done on a source file or 
project level. Alternatively, one can group suitable source files 
together; but this requires more work.

In development work, if COIN uses UNITY_BUILD, there is also a small 
risk of changes with missing header files being accepted.

Summmarising: we stand to gain a speed-up of compilation; particularly 
for clean builds like in COIN; but it requires some work. We might do a 
step-by step approach process enabling modules one by one. What do you 
think?

Regards, Friedemann

-- 

Friedemann Kleint
The Qt Company GmbH



More information about the Development mailing list