> On Friday, December 4, 2015, Daniel Pfeifer <dan...@pfeifer-mail.de> wrote: >> >> My working branch is here: >> https://github.com/purpleKarrot/CMake/commits/pch >> >> Feel free to comment, evaluate, contribute. >> >> I am nut fully decided regarding these two questions: >> - Do we want to support different pch per CONFIG? I think no, but I >> might be wrong. >> - Do we want to support different pch per LANGUAGE? I first thought >> yes, but I am no longer certain about that.
On Fri, Dec 4, 2015 at 2:42 PM, David Cole <dlrd...@aol.com> wrote: > With Visual Studio, you definitely **need** separate pch for each CONFIG. > Every pch is going to include headers which have Debug/Release differences > in them, and it is not safe to mix and match compiler output from separate > configs together. Maybe we are confusing two things here. Visual Studio compiles a pch-binary for each configuration. That pch-binary is probably incompatible with other configurations. In my current implementation, the header file that is used to compile the pch-binary is generated by CMake, using information provided by the user. This approach is very powerful, as it supports usage requirements. See here for an example: You can see here: https://github.com/purpleKarrot/CMake/blob/e441eac5b16fd245e6aa014867d43d53c18b6d4d/Tests/PrecompileHeaders/CMakeLists.txt My question actually boils down to whether CMake should (a) generate a header file for each configuration/language, or (b) generate a **single** header file which is then precompiled for all configurations/languages. Both approaches are possible, because we can use #ifdef __cplusplus etc. More importantly: Do we want the user to (c) tell CMake about different headers-to-be-precompiled per config/language so CMake can write the appropriate #ifdefs into the generated file, or (d) put #ifdefs into the provided file so that CMake can #include it in the generated file without any additional logic? Again both approaches are technically possible. It is not about what we **need**, but what we **want**. And there, I am undecided. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
