[Development] Proposing CMake as build tool for Qt 6
Mark De Wit
mark.dewit at iesve.com
Mon Jun 17 11:45:34 CEST 2019
> -----Original Message-----
> From: Development <development-bounces at qt-project.org> On Behalf Of
> Konstantin Tokarev
> Sent: 06 June 2019 14:30
> To: Simon Hausmann <simon.hausmann at qt.io>; Bogdan Vatra
> <bogdan.vatra at kdab.com>; development at qt-project.org
> Subject: Re: [Development] Proposing CMake as build tool for Qt 6
> 06.06.2019, 16:25, "Simon Hausmann" <simon.hausmann at qt.io>:
> > Hi,
> > Regarding PCH, it seems that right now it would be easiest to include
> something like https://github.com/sakra/cotire . Patches are welcome to
> integrate this or alternatively work with upstream CMake for a built-in
> Yet another alternative is https://github.com/larsch/cmake-precompiled-
> which is not so monstrous as cotire
I have used Cotire until recently and would caution against it. The library at its core is a clever idea but its implementation caused a lot of build instability for us. Its current version doesn't work on MSVC with CMake > 3.12, also fails on Mac with AppleClang 8.0 (bad command line parameter). It appears to be unmaintained as my bug reports have gone completely unanswered / not even acknowledged.
In the end I wrote my own pch script that works ok for our scenario. MSVC support is pretty trivial, gcc/clang more awkward because their pch compilation is a separate build step. My script did include some ideas from larsch github repo linked above, but I don't like his approach of injecting build flags into the clang/gcc pch stage (it didn't work for me, I ended up missing critical flags).
I used some ideas from cotire to generate a list of includes to seed each module PCH header file, but maintain updates manually (like MSVC stdafx.h/pch.h approach). I'm sure pch header generation could be automated too...
More information about the Development