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

[Daniel Pfeifer]

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?