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

[Daniel Pfeifer]

> On Friday, December 4, 2015, Daniel Pfeifer <daniel at pfeifer-mail.de> wrote:
>>
>> My working branch is here:
>> https://github.com/purpleKarrot/CMake/commits/pch
>>
>> Feel free to comment, evaluate, contribute.
>>
>> I am nut fully decided regarding these two questions:
>> - Do we want to support different pch per CONFIG? I think no, but I
>> might be wrong.
>> - Do we want to support different pch per LANGUAGE? I first thought
>> yes, but I am no longer certain about that.

On Fri, Dec 4, 2015 at 2:42 PM, David Cole <DLRdave at aol.com> wrote:
> With Visual Studio, you definitely **need** separate pch for each CONFIG.
> Every pch is going to include headers which have Debug/Release differences
> in them, and it is not safe to mix and match compiler output from separate
> configs together.

Maybe we are confusing two things here.

Visual Studio compiles a pch-binary for each configuration. That
pch-binary is probably incompatible with other configurations.
In my current implementation, the header file that is used to compile
the pch-binary is generated by CMake, using information provided by
the user.

This approach is very powerful, as it supports usage requirements. See
here for an example:
You can see here:
https://github.com/purpleKarrot/CMake/blob/e441eac5b16fd245e6aa014867d43d53c18b6d4d/Tests/PrecompileHeaders/CMakeLists.txt

My question actually boils down to whether CMake should
(a) generate a header file for each configuration/language, or
(b) generate a **single** header file which is then precompiled for
all configurations/languages.

Both approaches are possible, because we can use #ifdef __cplusplus etc.

More importantly: Do we want the user to
(c) tell CMake about different headers-to-be-precompiled per
config/language so CMake can write the appropriate #ifdefs into the
generated file, or
(d) put #ifdefs into the provided file so that CMake can #include it
in the generated file without any additional logic?

Again both approaches are technically possible. It is not about what
we **need**, but what we **want**. And there, I am undecided.