[cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation

Adam Strzelecki ono at java.pl
Sun Mar 1 09:11:29 EST 2015


>> Yes, it was meant to work with Makefiles and Ninja.
> Okay, I'll give it a shot with Ninja and report back.

Thanks.


>> Not at the moment, but C support double be just copy&paste replacing "CXX" with "C". I'll add it to the TODO.
> Thank you. ReactOS is mostly C so lack of its support prevents us from testing it on ReactOS.

I've pushed new change that adds plain C language support.


> I noticed two things so far:
> * It seems target centric, what about targets where we want PCH to cover a specific set of source files, not all the source files of a target? I ask because in ReactOS, for example, we are forced to compile GUID related source files without PCH in order for them to work. Other cases can be when some source files requires flags/defines applied to headers that belong to the PCH but are not present in other source files. Is there a way to achieve that?

Nope. But let's say I'll add such setting:

	target_precompiled_header(target SOURCES <list of sources>)

Then instead of applying precompiled header to all target sources, it will apply just for these specified here. However this may generate suboptimal Makefiles/Ninja files since for many (thousands of) files, every file will have separate flags specified which is IMHO pretty bad.

It would be better to separate guid non-PCH sources into separate object only library via:

	add_library(target_guid_files OBJECT sources)

And then add these output files to main target using PCH via $<TARGET_OBJECTS:target_guid_files>


> * The shared idea means you can create a target just to hold a PCH, then make the rest of targets share that PCH?

Yes! But unfortunately this may NOT work for MSVC. Since this implies we would need to share PDB. But this is somehow Microsoft specific stuff.

-- Adam



More information about the cmake-developers mailing list