On Fri, May 18, 2012 at 12:07 PM, Bill Hoffman <bill.hoff...@kitware.com>wrote:
> On 5/18/2012 12:51 PM, Robert Dailey wrote:
>
>
>> 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!
>>
>
>
> I agree, I hate to see code duplication. We do have a test to make sure it
> is possible that is run each night:
>
> Tests/PrecompiledHeader
>
>
> I have never used it, so I am not sure how hard it is. I am thinking
> maybe the thing to do is create a module for each compiler that we add
> support for PCH. Something like Modules/MSVCPCH.cmake. Since it is so
> compiler specific. Then the implementation would be in cmake code in a
> module and it will be clear that it is for one compiler. Perhaps you could
> generalize what you have already done into a module like this that could be
> included in CMake?
I'd be more than happy to do that, however my setup is a little different
from what you're suggesting. I basically have something like this (pseudo
code):
function( precompiled_headers )
if( MSVC )
....
elseif( GCC )
....
else()
# Not supported
endif()
endfunction()
If you are wanting to split it out into separate modules, the logic above
would be the responsibility of the client. In other words, CMake wouldn't
help the user choose the right CMake PCH module depending on their target
compiler. Am I misunderstanding your idea?
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
