|
Notes |
|
|
(0001619)
|
|
kireputsje
|
|
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.
|
|
|
|
(0001620)
|
|
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. |
|
|
|
(0001621)
|
|
kireputsje
|
|
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.
|
|
|
|
(0001623)
|
|
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...)
Example:
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. |
|
|
|
(0005251)
|
|
Brad King
|
|
2006-10-05 11:42
|
|
Bug 0000907 has been closed as a duplicate of this bug.
|
|
|
|
(0005402)
|
|
Brad King
|
|
2006-10-13 17:16
|
|
Bug 0003512 is closed as a duplicate of this.
|
|
|
|
(0005567)
|
|
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.
|
|
|
|
(0006346)
|
|
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.
|
|
|
|
(0006473)
|
|
axel.roebel
|
|
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. |
|
|
|
(0008498)
|
|
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.
Example:
# 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
ADD_EXECUTABLE(ProjectName
${ProjectName Src}
${ProjectName Include}
${ProjectName Resource}
...
${ProjectName_pch}
)
ADD_NATIVE_PRECOMPILED_HEADER(ProjectName ./Precompiled.h)
|
|
|
|
(0008734)
|
|
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?
|
|
|
|
(0010865)
|
|
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.
|
|
|
|
(0011853)
|
|
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 |
|
|
|
(0012563)
|
|
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}")
ENDFOREACH(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}")
+ ENDFOREACH(item)
+# MESSAGE("_directory_flags ${_directory_flags}" )
GET_DIRECTORY_PROPERTY(_directory_flags DEFINITIONS)
- #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} ) |
|
|
|
(0014137)
|
|
Rodolfo Schulz de Lima
|
|
2008-11-19 15:04
|
|
|
Is this bug being worked on? Anything that I could help? |
|
|
|
(0014470)
|
|
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. |
|
|
|
(0014536)
|
|
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,
STRING(TOUPPER "${CMAKE_BUILD_TYPE}" BUILD_TYPE)
IF(${BUILD_TYPE} STREQUAL "DEBUG")
ADD_DEFINITIONS(-DQT_DEBUG)
ENDIF(${BUILD_TYPE} STREQUAL "DEBUG") |
|
|
|
(0014540)
|
|
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
ut_pch_dephelp.cxx
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
ut_pch_dephelp.cxx
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'
Stop.
Please correct me if I'm wrong.
|
|
|
|
(0014553)
|
|
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 |
|
|
|
(0014942)
|
|
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.
Thanks |
|
|
|
(0014943)
|
|
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. |
|
|
|
(0020398)
|
|
Andreas Mohr
|
|
2010-04-26 07:31
|
|
Important nit:
In PCHSupport_26.cmake ,
ADD_CUSTOM_COMMAND(
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
add_definitions(-DTXT_DLL=\"mylib.dll\")
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"
message.
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
Thanks! |
|
|
|
(0021146)
|
|
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)
ENDMACRO(_PCH_WRITE_PCHDEP_CXX ) |
|
|
|
(0021475)
|
|
indy2718
|
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)
|
|
|
|
(0023633)
|
|
Andreas Mohr
|
|
2010-12-01 03:23
|
|
Next nit:
macro ADD_PRECOMPILED_HEADER_TO_TARGET(),
SET_TARGET_PROPERTIES(${_targetName}·
PROPERTIES»·
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. |
|
|
|
(0025392)
|
|
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?
|
|
|
|
(0027263)
|
|
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... ;) |
|
|
|
(0029647)
|
|
Graham Perks
|
|
2012-06-08 11:16
|
|
There's a simple option for Xcode builds. Add these two lines for each target:
SET_TARGET_PROPERTIES(target_name PROPERTIES XCODE_ATTRIBUTE_GCC_PRECOMPILE_PREFIX_HEADER YES)
SET_TARGET_PROPERTIES(target_name PROPERTIES XCODE_ATTRIBUTE_GCC_PREFIX_HEADER "include/prefix header.h") |
|
|
|
(0030818)
|
|
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++.
https://github.com/sakra/cotire/ [^] |
|
|
|
(0031052)
|
|
Andreas Mohr
|
|
2012-09-18 17:53
|
|
Some months ago I decided to add the PCH module to my project at http://sf.net/projects/vcproj2cmake, [^] 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).
Thanks! |
|
|
|
(0031149)
|
|
JussiP
|
|
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)
add_custom_command(...
-----
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. |
|
|
|
(0031150)
|
|
Yuchen Deng
|
|
2012-10-02 08:26
|
|
|
|
|
(0031216)
|
|
Andrey
|
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.
|
|
|
|
(0031217)
|
|
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!). |
|
|
|
(0031218)
|
|
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. |
|
|
|
(0031219)
|
|
Yuchen Deng
|
|
2012-10-11 18:53
|
|
|
hi, Amine, try 2.8.10-rc1. |
|
|
|
(0031220)
|
|
Amine Khaldi
|
|
2012-10-11 20:35
|
|
|
Hi, I did those tests with cmake head. |
|
|
|
(0031987)
|
|
Peter Kuemmel
|
|
2013-01-05 03:15
|
|
To simplify the adding of pch related rules I tried a different approach:
The patch
0001-add-source-file-properties-EXTERNAL_SOURCE-and-OBJEC.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
Tests/SourceFileProperties/CMakeLists.txt
The patch should only show the idea and is not ready for committing. |
|
|
|
(0034505)
|
|
Andrey
|
|
2013-11-20 13:18
|
|
Peter Kuemmel
Can hope these properties will be the default in CMake 3.0??? without paches??? |
|
|
|
(0034573)
|
|
Peter Kuemmel
|
|
2013-11-26 12:47
|
|
|
|
|
(0038213)
|
|
Peter Kuemmel
|
|
2015-03-14 04:54
|
|
|
|
|
(0040299)
|
|
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)... |
|
|
|
(0040301)
|
|
Dino Gustin
|
|
2016-01-22 08:56
|
|
|
We desperately need this fixed. |
|
|
|
(0040302)
|
|
Ivan Jurin
|
|
2016-01-22 08:56
|
|
|
I strongly agree with Marko |
|
|
|
(0040303)
|
|
Ivan Grce
|
|
2016-01-22 08:57
|
|
|
|
|
(0040305)
|
|
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 (https://github.com/sakra/cotire [^]), CMakePCHCompiler (https://github.com/nanoant/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 (https://github.com/larsch/cmake-precompiled-header/blob/master/PrecompiledHeader.cmake [^]) 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. |
|
|
|
(0040820)
|
|
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. |
|
|
|
(0041296)
|
|
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. |
|
PCHSupport.cmake (7,798) 1969-12-31 19:00
NativePrecompiledd headers support.zip (4,813) 2007-08-17 11:46
0001-add-source-file-properties-EXTERNAL_SOURCE-and-OBJEC.patch (11,821) 2013-01-05 03:05