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

David Cole DLRdave at aol.com
Fri Dec 4 17:32:38 EST 2015

Makes sense.

Can I inject my own "#include <notNormallyIncludedSystemHeader>" into
the generated stream, or otherwise inject something into it?

Specifically, for me, I want to include some, but not ALL VTK headers
for a VTK-based project.

Thanks for working on this.

Let me know if you want me to be a Visual Studio tester for you.


On Fri, Dec 4, 2015 at 5:28 PM, Daniel Pfeifer <daniel at pfeifer-mail.de> wrote:
> On Fri, Dec 4, 2015 at 9:19 PM, David Cole <DLRdave at aol.com> wrote:
>> Right, I was talking about the pch-binary.
>> Why would CMake even need to generate a header file for pre-compiled
>> headers? Why not just allow the user to say which of his header files
>> should be the one to use for precompiled headers?
> Generating a header file is necessary for two reasons:
> 1. In GCC, the compiled pch-binary has to be located in the same
> directory as the pch-source header. For out-of-source-builds, we
> certainly do not want to clutter the source directory, so we need a
> header file inside the binary directory. We could create a copy
> (fragile), a symlink (not portable), or a forward-#include
> (preferred).
> 2. There can be only one pch per target. See below.
>> I have a project I work on which is a VS-only non-CMake based project,
>> where we name the pch input header files as "${libraryName}PCH.h" and
>> anything we want included in the pch-binary we can just add to that
>> file.
>> Personally, I would prefer to have a manually edited file as the input
>> to precompiled header so I can add whatever I want in there.
> That is perfectly reasonable. This is also the reason why I think the
> config/language specific differences should **not** be handled by
> CMake, but by the user.
>> What would be in the contents of the generated header? How do you know
>> how much or how little is reasonable to put in there? Seems like a
>> per-library / per-project sort of decision.
> If you look at the example I referred to, there is a library `foo`
> with a pch `foo.h` as a usage requirement. There is also an interface
> library `bar` with a pch `bar.h` as a usage requirement. Then there is
> an executable `foobar` which links against both `foo` and bar`. So the
> generated pch-source for the `foobar` target will contain:
> ----
> /* This file is generated by CMake */
> #include <foo.h>
> #include <bar.h>
> ----
> Making sense?

More information about the cmake-developers mailing list