On 17 Jan 2023, at 13:35, Edward Welbourne via Development <development@qt-project.org> wrote:
On Monday, 16 January 2023 04:49:23 PST Friedemann Kleint via Development wrote: 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? On 17.01.23 05:09, Thiago Macieira wrote: I was going to object to it being in COIN, but considering it may improve build times in the CI, especially for constrained platforms (like macOS), I withdraw my objection before I even make it. I think this effort is worth it. Christian Tismer-Sperling (17 January 2023 11:55) asked: What was the reason that you first considered to object to it? While I can't be sure what Thiago was thinking of, one obvious objection to doing this in Coin would be that: if someone changes a source file in a way that needs a #include addition to the changed source file, but Coin's Unity build combines that file with one that has the #include, Coin won't notice, the change will get integrated and those doing a non-Unity builds, or for whom the Unity build splits files up differently, may find themselves with broken builds. I imagine there are other mistakes that can likewise be concealed by a Unity build. Eddy. I would actually turn Thiago’s objection on its head and ask that we have at least one configuration in COIN that verifies that UNITY_BUILDs work, if we agree that this is a good idea. Better usage of our CI capacity is good for the project, so anything that helps speeding up the build time with reasonable, sustainable effort is good. Since making UNITY_BUILDs work require unintuitive changes (such as having to disambiguate names that look like they are local to a translation unit), we should make sure that we don’t break such builds with the next commit adding a static function or a symbol in the anonymous namespace. In the short term I don’t expect that this will improve effective CI performance considerably, at least not until every CI configuration uses UNITY_BUILDs. The spread of build times in e.g. https://testresults.qt.io/coin/integration/qt/qtbase/tasks/1681530493 is wild (from a few minutes to almost 1.5hours). No idea why windows-11_22h2-mingw11-developer-build is so slow, but in the end, the slowest platform for building and testing defines the time we have to wait until we know that our changes were good (failing build or test shortcuts that, of course). But small steps. And as long as we have only a few UNITY_BUILD-configurations, it seems unlikely that we don’t catch changes that break non-UNITY_BUILDs in other configurations. So, I like the idea. The amount of code we would have to touch seems comparatively small, so we shouldn't end up with a ton of code churn that breaks cherry-picks to older branches. However, I’d like to understand the pros and cons of the different mechanism cmake gives us to prevent issues. If the downside of excluding files with e.g. ambiguous statics from UNITY_BUILDs is small, then would that be a better approach than putting some _qt_xyx_ prefix in front of every static, at least as a first step? Volker
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
