MantisBT - CMake
View Issue Details
0001260CMakeCMakepublic2004-10-18 10:052016-06-10 14:30
Bojan Resnik 
Kitware Robot 
0001260: Support for precompiled headers
Many popular C/C++ compilers, including VC++, Borland and GCC support creation and usage of precompiled headers.
  Currently, CMake does not directly support precompiled headers, so the only way to deal with them is to use SET_SOURCE_FILES_PROPERTIES with appropriate compiler-specific switches. This, however, requires conditional code for each supported compiler and has an additional drawback that it doesn't map well into some development environments. For instance, VC++ DSP/VCPROJ files have a special setting related to precompiled files, which is not affected by the current workaround.
  It would be a great benefit if CMake were to support precompiled headers in a generic and compiler-independent way, perhaps with special commands for creating and using precompiled headers on source file level, and not on target level. For compilers that do not support this feature, precompiled headers can be silently ignored, because a project that uses precompiled headers can always be compiled without them (usually slower).
No tags attached.
has duplicate 0013567closed  Add functionality to help users write precompiled header support 
? PCHSupport.cmake (7,798) 1969-12-31 19:00
zip NativePrecompiledd headers (4,813) 2007-08-17 11:46
? PCHSupport_rodlima.cmake (7,750) 2008-03-19 22:08
? PCHSupport_26.cmake (10,689) 2008-05-13 09:38
? PCH_GCC4.cmake (1,222) 2010-07-26 01:37
? PCH_GCC4_v2.cmake (1,239) 2010-07-26 16:59
patch 0001-add-source-file-properties-EXTERNAL_SOURCE-and-OBJEC.patch (11,821) 2013-01-05 03:05
Issue History
2007-08-17 11:46Gabriel BeaucheminFile Added: NativePrecompiledd headers
2007-08-17 11:49Gabriel BeaucheminNote Added: 0008498
2007-08-17 21:08Gabriel BeaucheminNote Edited: 0008498
2007-08-29 11:50Rodolfo Schulz de LimaNote Added: 0008734
2007-08-30 08:37Rodolfo Schulz de LimaNote Edited: 0008734
2008-03-19 22:07Rodolfo Schulz de LimaNote Added: 0010865
2008-03-19 22:08Rodolfo Schulz de LimaFile Added: PCHSupport_rodlima.cmake
2008-03-19 22:09Rodolfo Schulz de LimaNote Edited: 0010865
2008-05-13 09:35Gabriel BeaucheminNote Added: 0011853
2008-05-13 09:38Gabriel BeaucheminFile Added: PCHSupport_26.cmake
2008-06-28 07:37Evgeniy DushistovNote Added: 0012563
2008-11-19 15:04Rodolfo Schulz de LimaNote Added: 0014137
2009-01-07 01:27Yevgen MuntyanNote Added: 0014470
2009-01-12 13:17Matt MeltonNote Added: 0014536
2009-01-13 01:09Slava TutushkinNote Added: 0014540
2009-01-13 01:12Slava TutushkinNote Edited: 0014540
2009-01-14 11:54Matt MeltonNote Added: 0014553
2009-02-16 05:11Benjamin SchindlerNote Added: 0014942
2009-02-16 09:30Brad KingNote Added: 0014943
2010-04-26 07:31Andreas MohrNote Added: 0020398
2010-06-23 14:08Andreas MohrNote Added: 0021146
2010-07-26 01:37indy2718File Added: PCH_GCC4.cmake
2010-07-26 01:40indy2718Note Added: 0021475
2010-07-26 15:59indy2718Note Edited: 0021475
2010-07-26 16:59indy2718File Added: PCH_GCC4_v2.cmake
2010-07-26 17:00indy2718Note Edited: 0021475
2010-12-01 03:23Andreas MohrNote Added: 0023633
2011-02-11 10:16Olaf van der SpekNote Added: 0025392
2011-02-11 10:19Olaf van der SpekNote Edited: 0025392bug_revision_view_page.php?bugnote_id=25392#r197
2011-02-11 10:21Brad KingAssigned ToBrad King =>
2011-02-11 10:21Brad KingStatusassigned => backlog
2011-08-23 11:45Andreas MohrNote Added: 0027263
2012-06-08 11:16Graham PerksNote Added: 0029647
2012-09-02 09:09Yuchen DengNote Added: 0030818
2012-09-18 17:53Andreas MohrNote Added: 0031052
2012-10-02 08:01Brad KingRelationship addedhas duplicate 0013567
2012-10-02 08:10JussiPNote Added: 0031149
2012-10-02 08:26Yuchen DengNote Added: 0031150
2012-10-11 12:42AndreyNote Added: 0031216
2012-10-11 14:17Andreas MohrNote Added: 0031217
2012-10-11 14:42Amine KhaldiNote Added: 0031218
2012-10-11 18:53Yuchen DengNote Added: 0031219
2012-10-11 20:35Amine KhaldiNote Added: 0031220
2012-10-12 00:27AndreyNote Edited: 0031216bug_revision_view_page.php?bugnote_id=31216#r855
2013-01-05 03:05Peter KuemmelFile Added: 0001-add-source-file-properties-EXTERNAL_SOURCE-and-OBJEC.patch
2013-01-05 03:15Peter KuemmelNote Added: 0031987
2013-11-20 13:18AndreyNote Added: 0034505
2013-11-26 12:47Peter KuemmelNote Added: 0034573
2015-03-14 04:54Peter KuemmelNote Added: 0038213
2016-01-22 08:30Marko MihovilicNote Added: 0040299
2016-01-22 08:56Dino GustinNote Added: 0040301
2016-01-22 08:56Ivan JurinNote Added: 0040302
2016-01-22 08:57Ivan GrceNote Added: 0040303
2016-01-22 09:17Nenad MikšaNote Added: 0040305
2016-04-06 06:02Nenad MikšaNote Added: 0040820
2016-06-10 14:27Kitware RobotNote Added: 0041296
2016-06-10 14:27Kitware RobotStatusbacklog => resolved
2016-06-10 14:27Kitware RobotResolutionopen => moved
2016-06-10 14:27Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:30Kitware RobotStatusresolved => closed

2004-10-18 15:09   
Just some thoughts:

In general you do not want every header to be pre-compiled. Most of the time a central header is sufficient, so the user should be able to state which headers needs precompiling. Something like:
ADD_PRECOMPILED_HEADERS( header1.h header2.h )

For gcc >= 3.4 you could just compile the header files, but with all flags, that would also be given to the program.
gcc -c header1.h -o header1.gch ... option ...

For MVSC you could create some dummy.cpp, which only includes the headers:
#include "header1.h"
#include "header2.h"

Then compile this file with /Yc, to create the pre-compiled header.
All the files in the project can than be compiled with an additional /Yu option.

Regards, Erik.
Bojan Resnik   
2004-10-18 15:41   
I do not really know about GCC, but for MSVC and Borland, a single header file is sufficient. Using precompiled headers in a project follows a scenario similar to this:
  - create a header file that will be precompiled (e.g. precompiled.hpp)
  - create a source file which will be used to create the precompiled header file (e.g. precompiled.cpp) and use the "create precompiled header" compiler option (-Ycprecompiled.hpp for MSVC)
  - for all other source files which use the precompiled headers, use the "use precompiled header" compiler option (-Yuprecompiled.hpp for MSVC).

I suppose it is possible to specify multiple headers to be precompiled, however I believe that this situation is highly uncommon and perhaps indicates that a project should be split into subprojects.

In my experience, it is a bad choice to leave to the compiler to decide which headers to precompile (by using plain -Yc and -Yu for MSVC), since in many situations it will even slow down compilation of other project files.
2004-10-18 15:58   
No problems whatever. We totally agree.
Off course I meant: /Yufilename and /Ycfilename. Possibly also /Fpfilename.pch
Also one header is sufficient in almost all cases, but I think we should not limit cmake, to the rare cases.
Bojan Resnik   
2004-10-20 04:44   
I agree that CMake should allow for the alternate possibilities. I would suggest a syntax like:

ADD_PRECOMPILED_HEADER(header-name source-file-to-create-the-precompiled-header)

USE_PRECOMPILED_HEADER(header-name file1 file2...)


ADD_PRECOMPILED_HEADER(precompiled.hpp precompiled.cpp)

USE_PRECOMPILED_HEADER(precompiled.hpp Main.cpp Foo.cpp Bar.cpp)

I think this would allow the user to have multiple precompiled headers by specifying multiple ADD_PRECOMPILED_HEADER() commands. CMake would also have to make sure that the source files which create the precompiled header are on top of the build tree.
Brad King   
2006-10-05 11:42   
Bug 0000907 has been closed as a duplicate of this bug.
Brad King   
2006-10-13 17:16   
Bug 0003512 is closed as a duplicate of this.
Brad King   
2006-10-26 16:44   
Bug 0003512 has been re-opened. It asks for a small change that enables PCH support to be handled through a low-level interface of directly specifying flags in target and source file properties.

This bug asks for a platform-independent high-level interface for using PCH.
Brad King   
2007-02-05 11:45   
Bug 0003512 has been fixed. As of CMake 2.4.7 it will be possible to use the VS precompiled header flags.
2007-02-20 10:24   
I uploaded the current version of the PCHSupport.cmake module written initially by maik beckmann, with changes suggested by frederic heem
and myself. The current version works with cmake 2.4.5 and above, supports automatic dependency handling and distcc.

As long as cmake does not support precompiled headers this module ma be helpful to others.
Gabriel Beauchemin   
2007-08-17 11:49   
(edited on: 2007-08-17 21:08)
Hi everyone.

I just extended the PCHSUpport to use "native" precompiled headers from Visual and XCode. This methods doesn't add intermediate targets.

For Xcode, the cmake code (cmGlobalXCodeGenerator.cxx) has been modified to process GCC_xxx as build settings.


# Also get the precompiled headername (if one exists, can be generated for Visual)
GET_NATIVE_PRECOMPILED_HEADER(ProjectName ./Precompiled.h)

# here we instruct CMake to build "ProjectName" executable from all of the source files
    ${ProjectName Src}
    ${ProjectName Include}
    ${ProjectName Resource}

ADD_NATIVE_PRECOMPILED_HEADER(ProjectName ./Precompiled.h)

Rodolfo Schulz de Lima   
2007-08-29 11:50   
(edited on: 2007-08-30 08:37)
using the attached PCHSupport.cmake with cmake-2.4.7, "make clean" is deleting the header source to be precompiled, there is a bug somewhere... can anyone confirm this?

Rodolfo Schulz de Lima   
2008-03-19 22:07   
(edited on: 2008-03-19 22:09)
It's been a while I'm using a derived script for creating precompiled headers that works with gcc and Visual Studio. I've made some changes on PCHSupport.cmake, simplifying it on gcc where you only need the precompiled header (and no source file) to create the gch. I'll attach it here for it to be reviewed. It's not the best way to do it, but it works with me, and IMHO it's about time for cmake support precompiled headers.

Although it should work flawlessly with Visual C++, it's been a while I didn't test it and I don't remember if I did something wrong that would break VC compatibility... this should be tested again.

Gabriel Beauchemin   
2008-05-13 09:35   
I've updated the PCHSupport.cmake to work properly with cmake 2.6 (no modifications needed. A far as I'm concerned, this is closed.

Thanks, B. King
Evgeniy Dushistov   
2008-06-28 07:37   
This macros not catch things like "-DQT_DEBUG", defnitions that depend on build_type:

--- /home/evgeniy/downloads/PCHSupport_26.cmake 2008-06-28 15:43:00.000000000 +0400
+++ cmake/PCHSupport_26.cmake 2008-06-28 15:31:20.000000000 +0400
@@ -58,9 +58,20 @@
   FOREACH(item ${DIRINC})
     LIST(APPEND ${_out_compile_flags} "${_PCH_include_prefix}${item}")
+ SET(_build_type "${CMAKE_BUILD_TYPE}")
+# MESSAGE(STATUS "build type: `${CMAKE_BUILD_TYPE}'")
+ IF (NOT _build_type)
+ SET(_build_type "Debug")
+ ENDIF (NOT _build_type)
+ string(TOUPPER ${_build_type} _build_type)
+ SET(_def_name "COMPILE_DEFINITIONS_${_build_type}")
+ GET_DIRECTORY_PROPERTY(_directory_flags ${_def_name})
+ FOREACH(item ${_directory_flags})
+ LIST(APPEND ${_out_compile_flags} "-D${item}")
+# MESSAGE("_directory_flags ${_directory_flags}" )
- #MESSAGE("_directory_flags ${_directory_flags}" )
+# MESSAGE("_directory_flags ${_directory_flags}" )
   LIST(APPEND ${_out_compile_flags} ${_directory_flags})
   LIST(APPEND ${_out_compile_flags} ${CMAKE_CXX_FLAGS} )
Rodolfo Schulz de Lima   
2008-11-19 15:04   
Is this bug being worked on? Anything that I could help?
Yevgen Muntyan   
2009-01-07 01:27   
In addition to Evgeniy Dushistov's additions, one also needs to use COMPILE_DEFINITIONS property (Evgeniy only did COMPILE_DEFINITIONS_<CONFIG>).

Cmake folks, pretty pretty please implement this? It's just too hard to do it outside cmake, given how build configuration is controlled by dozens of properties and variables and whatnot; any solution which works now will probably break with the next cmake version.
Matt Melton   
2009-01-12 13:17   
>> "make clean" is deleting the header source to be precompiled, there is a bug somewhere... can anyone confirm this?

I can confirm the attached PCHSupport_26.cmake does this. Luckily my editor was still open.

>> This macros not catch things like "-DQT_DEBUG", defnitions that depend on build_type:

This is a problem too. I have added manual check myself,

Slava Tutushkin   
2009-01-13 01:09   
(edited on: 2009-01-13 01:12)
The following is experienced with MSVC9

Looks like there are more problems with the implementation.
I have tried PCHSupport_26.cmake with the following code:

add_executable(ut stdafx.h TestUnittest.cpp SomeSuite.cpp SecondSuite.cpp TestSpace/TestClass.cpp)
add_precompiled_header(ut stdafx.h)

There are glitches:
1. Broken Visual Studio support. When trying to generate solution files, it complains on the absence of build type variable specified, which is makes no sense in the case of VS solution build.

2. Looks like it doesn't works for the out of source builds. It fails like that:

 [ 11%] Building CXX object CMakeFiles/ut_pch_dephelp.dir/ut_pch_dephelp.cxx.obj
C:\Prog\cmake\ut\build\release\ut_pch_dephelp.cxx(1) : fatal error C1083: Cannot
 open include file: 'stdafx.h': No such file or directory

Because that generated .cxx file tries to #include "stdafx.h", which is definitelly can't exist in the binary directory.

3. Even with the in-source build it fails with the following:
[ 12%] Building CXX object CMakeFiles/ut_pch_dephelp.dir/ut_pch_dephelp.cxx.obj
Linking CXX static library ut_pch_dephelp.lib
[ 12%] Built target ut_pch_dephelp
NMAKE : fatal error U1071: cycle in dependency tree for target 'stdafx.h'

Please correct me if I'm wrong.

Matt Melton   
2009-01-14 11:54   
I recommend trying a nightly cmake build (ie: 2.7), as there are some changes to the cvs PCHSupport version
Benjamin Schindler   
2009-02-16 05:11   
So, what's the status on this? It has been now over 4 years since this wish was reported.

Brad King   
2009-02-16 09:30   
Sorry, but doing this right as a first-class feature is very non-trivial. Every platform does PCH differently, so it is hard to define a common interface. It is probably possible, but we've not had the motivation/time/funding to do it.

Currently CMake does provide enough primitives for projects to do it themselves on each platform. For example, the OBJECT_OUTPUTS and OBJECT_DEPENDS properties can be used to do MSVC-style PCH dependencies in Makefile generators. Custom commands can achieve gcc-style PCH. I think the contributed scripts attached to this bug help with some of this.
Andreas Mohr   
2010-04-26 07:31   
Important nit:

In PCHSupport_26.cmake ,

    OUTPUT ${_output}
    COMMAND ${_command}
    DEPENDS ${_input} ${CMAKE_CURRENT_BINARY_DIR}/${_name} ${_targetName}_pch_dephelp

needs to have VERBATIM added, otherwise quoting of definitions
- e.g. as in the very common
case - is broken (causing a definition mismatch), thus use of precompiled header will unfortunately be skipped with a

#: cpppch.c:481
#, c-format
msgid "%s: not used because `%.*s' defined as `%s' not `%.*s'"
msgstr ""
"%s: nicht verwendet, da »%.*s« als »%s« statt als »%.*s« definiert wurde"


Took me more than an hour to nail that, attempting various quoting escapes etc.pp., with liberal use of message output to nail the exact place where things went wrong, until I finally discovered existence of add_custom_command VERBATIM keyword in some posting somewhere.

Keywords: cmake quotes quoting escape mismatch

Andreas Mohr   
2010-06-23 14:08   
Next important nit:

_PCH_WRITE_PCHDEP_CXX stupidly keeps pushing out the live dephelp file anew, causing eternal rebuilds of the precompiled header file on every invocation.

This can be fixed using the following patch:

--- PrecompiledHeader.cmake.orig_stupid_rebuild 2010-06-23 19:14:02.000000000 +0200
+++ PrecompiledHeader.cmake 2010-06-23 20:03:09.000000000 +0200
@@ -72,7 +72,7 @@
 MACRO(_PCH_WRITE_PCHDEP_CXX _targetName _include_file _dephelp)
   SET(${_dephelp} ${CMAKE_CURRENT_BINARY_DIR}/${_targetName}_pch_dephelp.cxx)
- FILE(WRITE ${${_dephelp}}
+ FILE(WRITE ${${_dephelp}}.in
 "#include \"${_include_file}\"
 int testfunction()
@@ -80,6 +80,10 @@
+ # use configure_file() to avoid re-touching the live file
+ # _every_ time thus causing eternal rebuilds
+ # (configure_file() does know to skip if unchanged)
+ configure_file(${${_dephelp}}.in ${${_dephelp}} COPYONLY)
2010-07-26 01:40   
(edited on: 2010-07-26 17:00)
Basic PCH_GCC4_v2.cmake for linux gcc 4.x attached. (fixed hard coded filename)

Andreas Mohr   
2010-12-01 03:23   
Next nit:

    COMPILE_FLAGS ${_target_cflags}·

will reset any COMPILE_FLAGS added to the target before configuring the target's precompiled header.
So either use set_property(... APPEND ...) or (to remain compatible with older CMake versions) keep using set_target_properties() and simply make sure to call get_target_properties() prior to that.
Olaf van der Spek   
2011-02-11 10:16   
(edited on: 2011-02-11 10:19)
> Sorry, but doing this right as a first-class feature is very non-trivial.

Moving the complexity into CMakeLists doesn't help users.

Is there a guide on how to do this for GCC?

Andreas Mohr   
2011-08-23 11:45   
Next nit:
File is missing lots of whitespace escaping (quotes),
e.g. when evaluating ADD_PRECOMPILED_HEADER _input argument.

To reproduce: copy CMakeCache.txt of a working build tree to an almost identically-named yet space-containing sibling directory, update CMakeCache.txt contents to properly have this space in all directory name variables, observe that a "cmake ." run can complete successfully, run a build, BOOM.

Yeah I know, spaces in filenames are evil, but... ;)
Graham Perks   
2012-06-08 11:16   
There's a simple option for Xcode builds. Add these two lines for each target:

Yuchen Deng   
2012-09-02 09:09   
Cotire (compile time reducer) is a CMake module that speeds up the build process of CMake based build systems by fully automating techniques as precompiled header usage and single compilation unit builds for C and C++. [^]
Andreas Mohr   
2012-09-18 17:53   
Some months ago I decided to add the PCH module to my project at, [^] file cmake/Modules/V2C_PCHSupport.cmake (definitely see experimental_unverified branch for latest version).

I've just done many fixes and structural corrections to this module. Frankly I was SHOCKED how incomplete/buggy the entire functionality still is, given the thoroughly medieval age of this issue.

You could probably consider vcproj2cmake official upstream of this module now, given that precompiled headers are quite obviously bound to be a required core feature of my project.

Due to these many quite recent corrections, testing (and related reports) would be very welcome (while I've got some variety available, I cannot test all environments myself).

2012-10-02 08:10   
The facilities CMake provides to create precompiled headers for GCC could be better.

To use precompiled headers with gcc, they must be compiled like this:

g++ [every single flag and option that would be given to source files] header.h -o header.h.gch

Those flags include stuff like -fPIC, -D flags and so on. If any one of them is missing, the produced file will not work.

Currently in CMake this list of flags is really hard to get to. There are two choices that I can see.

1) add a function to CMake that gives all command line switches for a given target. Then it could be used to build the pch like this


get_all_switches_for_target(switches targetname)
list(APPEND switches ${pch_file} -o ${CMAKE_CURRENT_BINARY_DIR}/${pch_file}.gch)


2) If you add the header to the list of source files and then do this:

set_property(SOURCE precompiled.h PROPERTY LANGUAGE CXX)

then CMake will build the pch correctly, but it will be called precompiled.o. GCC will not use it in this case. If there were an additional property which would allow the user to set the output file name (and tell CMake not to link the resulting object file in the target, because it will error out if you do), then the pch could be generated and used easily. Another issue is that CMake will not write the pch to BINARY_DIR but rather to BINARY_DIR/CMakeFiles/targetname.dir or somesuch. The exact path needs to be known in order to tell GCC where the pch is.

The difference between the two approaches is that the latter would automatically be part of dependency tracking. This is only an issue if you want to precompile your own headers. Most projects only use precompiled headers for system headers, such as
STL, Boost and/or Qt.
Yuchen Deng   
2012-10-02 08:26   
In these days, I am working to add CMake Scripts for QtCreator.
I've write a cmake file to support PCH, and now it works well for MSVC and GCC.
It still need a little work for CLang support.
See: [^]
2012-10-11 12:42   
(edited on: 2012-10-12 00:27)
If possible can add functional as property of source file. This property can mark to make only object file without add this object to target.

Andreas Mohr   
2012-10-11 14:17   
Andrey: that's something that I need to work towards as well, for the usual per-file settings in Visual Studio projects that "Create" the PCH for a project to possibly "Use". I started changing the implementation to be more flexible (extract compiler-specific flags via helper functions for this purpose, to *then* be used by other helper functions).

Yuchen: I'm rather unconvinced that it's very helpful to now even have a third incomplete solution in the making, after the module that was originally discussed here, and then cotire - which judging from short review seems to be quite elegant but not (yet?) very OOP-style in its function naming -, and now yours.

It would be very desireable after 8 years to achieve having one very modular, clean, concise, well-maintained and, above all, *complete* solution that works for all/most use cases (which easily may include fetching raw PCH compiler flags by the outside world sometimes!).
Amine Khaldi   
2012-10-11 14:42   
I would like to add that all the solutions mentioned above do not account for the fact that when using the ninja generator, the generated gch in the gcc builds doesn't have any dependency tracking, so if your pch includes some headers, and you alter one of them, the target won't get recompiled at all. I tried (on ReactOS codebase) basically every single implementation mentioned above, to no avail.
Yuchen Deng   
2012-10-11 18:53   
hi, Amine, try 2.8.10-rc1.
Amine Khaldi   
2012-10-11 20:35   
Hi, I did those tests with cmake head.
Peter Kuemmel   
2013-01-05 03:15   
To simplify the adding of pch related rules I tried a different approach:

The patch


introduces two new source file properties: EXTERNAL_SOURCE and OBJECT_LOCATION

With help of these properties the rules for gcc becomes much simpler, see

The patch should only show the idea and is not ready for committing.
2013-11-20 13:18   
Peter Kuemmel
Can hope these properties will be the default in CMake 3.0??? without paches???
Peter Kuemmel   
2013-11-26 12:47   
I started a thread on the ML: [^]
Peter Kuemmel   
2015-03-14 04:54   
Next attempt: [^]
Marko Mihovilic   
2016-01-22 08:30   
I would again (after the 11+ years that this issue is open) like to emphasise how important integrating this feature into cmake is. It is essential to use precompiled headers on larger projects to keep compile time at an acceptable level. The only proper way to use precompiled headers with cmake is by integrating it into the tool itself. Any additional "hacks" have various drawbacks (for instance, maintaining an explicit global target dependency ordered-list so that compile flags are properly resolved at PCH compilation) which if worked-around largely defeat the original purpose of using cmake (to have a simpler, maintainable, cross platform project structure) in the first place.

We would be prepared to submit patches/work with the developers on this issue if necessary since we currently spending more time on working with a retrofitted semi-solution to this problem (and I believe a lot of others are too)...
Dino Gustin   
2016-01-22 08:56   
We desperately need this fixed.
Ivan Jurin   
2016-01-22 08:56   
I strongly agree with Marko
Ivan Grce   
2016-01-22 08:57   
I agree with Marko
Nenad Mikša   
2016-01-22 09:17   
I totally agree with Marko. We are using CMake at our company to ensure our code could be compiled on all platforms (mac, linux, windows) with different generators (some of our developers prefer ninja, other makefiles, some xcode, other visual studio). Since our codebase is rather large we need to use precompiled headers to speed up the compilation. We tried using several approaches with third party solutions like cotire ( [^]), CMakePCHCompiler ( [^]), however neither of them worked for us - they generated lots of errors and were not forward compatible with latest CMake releases due to violating CMake policies introduced in later releases. They also had problems with support for certain combination of compiler and build system.

Eventually we ended up using custom modified script developed by Lars Christensen ( [^]) which worked best for us, but has its own problems. The most problematic one is obtaining correct set of compile options for target that need to be passed to clang/gcc on linux/mac. The problem is when target depends on another target which has its own specific compile options set in INTERFACE_COMPILE_OPTIONS, INTERFACE_COMPILE_DEFINITIONS and INTERFACE_INCLUDE_DIRECTORIES properties. So we need to recursively iterate over complete dependency graph of target to gather all compile options that need to be passed to PCH compile target.

Unfortunately, this trick does not work when a target depends on target will be defined later in configuration process (like for example when you have cyclic dependency). CMake correctly resolves all these compilation flags when building source files, however it is not possible to resolve them at configure time to properly generate PCH creation target. Therefore, there is a real need for CMake to natively support creation of PCH targets with build system (I think it's OK if CMake reports an error or does not use PCH if specific combination of compiler and build system does not support PCH).

We are using CMake 3.4.2 and we are in 2016., so it is really sad that such a wonderful tool like CMake does not natively precompiled headers.
Nenad Mikša   
2016-04-06 06:02   
Any progress on this? Various scripts around the internet do not work correctly for Xcode generator target.
Kitware Robot   
2016-06-10 14:27   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.