Makes sense.
Can I inject my own "#include <notNormallyIncludedSystemHeader>" into
the generated stream, or otherwise inject something into it?
Specifically, for me, I want to include some, but not ALL VTK headers
for a VTK-based project.
Thanks for working on this.
Let me know if you want me to be a Visual Studio tester for you.
D
On Fri, Dec 4, 2015 at 5:28 PM, Daniel Pfeifer <dan...@pfeifer-mail.de> wrote:
> On Fri, Dec 4, 2015 at 9:19 PM, David Cole <dlrd...@aol.com> wrote:
>> 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?
>
> Generating a header file is necessary for two reasons:
>
> 1. In GCC, the compiled pch-binary has to be located in the same
> directory as the pch-source header. For out-of-source-builds, we
> certainly do not want to clutter the source directory, so we need a
> header file inside the binary directory. We could create a copy
> (fragile), a symlink (not portable), or a forward-#include
> (preferred).
>
> 2. There can be only one pch per target. See below.
>
>> 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.
>
> That is perfectly reasonable. This is also the reason why I think the
> config/language specific differences should **not** be handled by
> CMake, but by the user.
>
>> 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.
>
> If you look at the example I referred to, there is a library `foo`
> with a pch `foo.h` as a usage requirement. There is also an interface
> library `bar` with a pch `bar.h` as a usage requirement. Then there is
> an executable `foobar` which links against both `foo` and bar`. So the
> generated pch-source for the `foobar` target will contain:
>
> ----
> /* This file is generated by CMake */
> #include <foo.h>
> #include <bar.h>
> ----
>
> Making sense?
--
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
