[CMake] Secret precompiled header support?

[Robert Dailey]

On Fri, May 18, 2012 at 9:51 AM, Bill Hoffman <bill.hoffman at kitware.com>wrote:

> On 5/17/2012 12:50 PM, Robert Dailey wrote:
>
>> Normally when you encounter "professional" software (that is, software
>> that you pay for, that is generally well designed and maintained by a
>> single entity), it has a consistent feel. Open source naturally can feel
>> inconsistent because of the large number of contributions, which
>> sometimes don't follow the same implementation patterns. I hope that
>> clarifies what I meant. An example, as I had stated, is general compiler
>> flag support. For example, we have convenience methods for includes and
>> preprocessor definitions, but PCH and warning levels does not have such
>> a thing.
>>
>>  I don't think this is an open source vs closed source thing either.  I
> think it is more of a cross platform thing.  I have used plenty of software
> that you pay for that is missing features or very buggy expect there is no
> way to fix it yourself...  Not that I am saying CMake is buggy and missing
> features.. :)
>
> What you are seeing in CMake is more a lack of cross platform support for
> PCH, and consistent warning levels in C++ compilers.  These things just are
> not consistent across various compilers and operating systems out there.
>  So, in those cases CMake has to step up and create a consistent API, which
> of course is much harder, and will have holes because various compiler
> won't support it. For example if we created some nice functions to do PCH,
> they would only work on a small percentage of the supported compilers.
> Coming up with a mapping of warning flags is just as challenging.
>
> However, include flags and preprocessor definitions are standard and
> "required" for a C++ compiler to work.  PCH and warning levels are not
> required to build C++, so those features are missing and vary in
> implementation across compilers.
>
> The idea behind CMake is to provide as consistent a cross platform
> interface to the build as possible.  However, we allow access to platform
> specific flags and settings so that projects that need to work on a
> specific platform can do so.
>
> Since, as you say "I am only a Windows developer", you should be able to
> put the windows specific PCH stuff into your project and it won't be too
> much of an issue for your project.
>
> All that said, it would be nice to have a better interface for PCH support
> that would work when it was available.  However, to date it has not been a
> high priority.
>
> So, not having these features has IMO little to do with CMake being
> professional or consistent, or Kitware taking CMake seriously, but rather
> with the difficulty of implementation and lack of standardization in C++
> compilers.


I certainly agree with all of your points but consider this. Even though
PCH support may not exist on every compiler, every company that wants to
add PCH support to CMake through scripting logic is essentially doing the
same work over and over again. Everybody is going to do the same things:

   1. Restrict the functionality to MSVC only via conditional branching
   2. Call the same CMake commands to add the same compiler flag with the
   same parameters

Just because every compiler doesn't support it doesn't mean CMake can't
provide some way to eliminate the boilerplate. If we want to use PCH
through CMake, there is certain logic that must exist. It's really just a
question of WHERE that should exist: In CMake C++ code or in CMake as a
script.

What do we do if PCH support isn't provided by a compiler, but we have
enabled it in our scripts? There are several things you can do, but what I
commonly do is just ignore the request. For example, for all platforms I
may invoke my custom function to enable PCH, but on the platforms that
don't support it, it's just going to make sure that those files get
compiled. Even if you don't enable PCH or can't use it, the PCH header file
is still included in all CPP files that need includes from it, so the code
will still compile. In this specific case, ignoring the request still
works, and the user doesn't have to worry about the lack of the feature
resulting in the build failing.

You know all of this but the main point I wanted to make is that even
though CMake can't guarantee PCH support on all platforms, it's still
adding value by eliminating boilerplate. People won't be redundantly
implementing and re-testing the same complex logic to add the feature in a
modular way. Maybe a good middle ground would be to have a CMake built in
module that provides "convenience" functions for operations like this. That
way, CMake C++ code isn't changing, but we still give the users a subset of
functionality to work with.

Just a thought!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20120518/192b1c1d/attachment.htm>