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

[Brad King]

On 03/03/2015 07:43 AM, Adam Strzelecki wrote:
> On 03/01/2015 08:02 PM, Ben Boeckel wrote:
>> On 02/28/2015 11:59 AM, Adam Strzelecki wrote:
>>      target_precompiled_header(<target> <path/to/precompiled_header.h>)
>> 
>>      target_precompiled_header(<target> <path/to/precompiled_header.h> SHARED
>>                                <other_target_to_share_precompiled_header_with>)
>> Could we rename this? Currently target_* functions are all related to
>> usage requirements and these are not usage requirements.
> 
> Honestly I don't understand your request. What would be then the name
> that better represents what the function does.

Currently the target_* commands are:

 target_compile_definitions
 target_compile_features
 target_compile_options
 target_include_directories
 target_link_libraries
 target_sources

They all have the general signature

 target_command(<target> [options] [<SCOPE> <items>...]...)

where <SCOPE> is INTERFACE, PUBLIC, or PRIVATE and affects whether the
settings apply to sources in the target itself and/or its dependents.
The proposed target_precompiled_header signature does not fit into
this layout.  Either a different command name is needed or one needs
to define the command signature and semantics to fit the above layout.
Do PCHs fit into usage requirements in any way?

There is discussion elsewhere in this thread is about re-using
precompiled headers across multiple targets.  Since every target can
have its own preprocessor definitions and other flags for the same
sources, this functionality needs to be used with care.  The interface
design should make this hard to do wrong if possible.

There is also discussion about consuming a PCH only in a subset of
sources for a target.  In principle the selection has to be separate
for each target/source pair.  The decision of whether to use an
approach that ends up with separate rules for specific source files
or to use an OBJECT library should be left up to the project author.
CMake should provide options for both alternatives.

> I want this to be handled natively adding some extra variables:
> 
> 	CMAKE_<LANG>_PRECOMPILE_HEADER
> 	
> 		GCC, Clang: same as CMAKE_<LANG>_COMPILE_OBJECT
> 		MSVC: CMAKE_<LANG>_COMPILE_OBJECT with "-c" replaced with "/FoNUL /Yc /Fp"
> 
> 	CMAKE_<LANG>_PRECOMPILED_HEADER_EXTENSION
> 
> 		GCC: .gch
> 		MSVC, Clang: .pch
> 
> 	CMAKE_PRECOMPILED_HEADER_FLAG_<LANG>

I think the name still start in "CMAKE_<LANG>_".

> 		GCC, Clang: -include <PATH>
> 		MSVC: /Yu<BASENAME> /Fp<PATH> /FI$<BASENAME>
> 
> And extending CMake to generate proper build commands for Makefile,
> Ninja targets, and also Xcode, MSVC generators.

Yes, please.  Thanks for offering to work on this.  This has been a
long-missing feature.  However, we need to get the abstractions and
interfaces right so a few rounds of discussion will be needed first.

-Brad