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?
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.
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.
D
On Fri, Dec 4, 2015 at 12:26 PM, Daniel Pfeifer <dan...@pfeifer-mail.de> wrote:
>> 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
