On 03/03/2015 07:43 AM, Adam Strzelecki wrote: > On 03/01/2015 08:02 PM, Ben Boeckel wrote: >> On 02/28/2015 11:59 AM, Adam Strzelecki wrote: >> target_precompiled_header(<target> <path/to/precompiled_header.h>) >> >> target_precompiled_header(<target> <path/to/precompiled_header.h> SHARED >> >> <other_target_to_share_precompiled_header_with>) >> Could we rename this? Currently target_* functions are all related to >> usage requirements and these are not usage requirements. > > Honestly I don't understand your request. What would be then the name > that better represents what the function does.
Currently the target_* commands are: target_compile_definitions target_compile_features target_compile_options target_include_directories target_link_libraries target_sources They all have the general signature target_command(<target> [options] [<SCOPE> <items>...]...) where <SCOPE> is INTERFACE, PUBLIC, or PRIVATE and affects whether the settings apply to sources in the target itself and/or its dependents. The proposed target_precompiled_header signature does not fit into this layout. Either a different command name is needed or one needs to define the command signature and semantics to fit the above layout. Do PCHs fit into usage requirements in any way? There is discussion elsewhere in this thread is about re-using precompiled headers across multiple targets. Since every target can have its own preprocessor definitions and other flags for the same sources, this functionality needs to be used with care. The interface design should make this hard to do wrong if possible. There is also discussion about consuming a PCH only in a subset of sources for a target. In principle the selection has to be separate for each target/source pair. The decision of whether to use an approach that ends up with separate rules for specific source files or to use an OBJECT library should be left up to the project author. CMake should provide options for both alternatives. > I want this to be handled natively adding some extra variables: > > CMAKE_<LANG>_PRECOMPILE_HEADER > > GCC, Clang: same as CMAKE_<LANG>_COMPILE_OBJECT > MSVC: CMAKE_<LANG>_COMPILE_OBJECT with "-c" replaced with > "/FoNUL /Yc /Fp" > > CMAKE_<LANG>_PRECOMPILED_HEADER_EXTENSION > > GCC: .gch > MSVC, Clang: .pch > > CMAKE_PRECOMPILED_HEADER_FLAG_<LANG> I think the name still start in "CMAKE_<LANG>_". > GCC, Clang: -include <PATH> > MSVC: /Yu<BASENAME> /Fp<PATH> /FI$<BASENAME> > > And extending CMake to generate proper build commands for Makefile, > Ninja targets, and also Xcode, MSVC generators. Yes, please. Thanks for offering to work on this. This has been a long-missing feature. However, we need to get the abstractions and interfaces right so a few rounds of discussion will be needed first. -Brad -- 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