On 09/01/2015 05:19 PM, Gilles Khouzam wrote: > For VS_DEFAULT_TARGET_PLATFORM_VERSION, what I'm trying to > achieve is almost an internal property that is used for the > try_compile phase. Since the generator is not used in that > scenario, the project is using the template from > Modules/CompilerId/VS-10.vcxproj.in. In that case, we need to set > the tag for the WindowsTargetPlatformVersion. During the > generation, I query for the latest SDK version in the > GlobalGenerator and set the VS_DEFAULT_TARGET_PLATFORM_VERSION > property that is then used in CMakeDetermineCompilerId.cmake to > set the variable that the template uses in the Windows 10 case.
The generator *is* used for try_compile calls. The template in Modules/CompilerId/VS-10.vcxproj.in is used *only* for the compiler identification step which occurs before we have enough information to do a full try_compile. The compiler id step does need special handling to set this value, but it should be based on however the value is determined for the generator normally. As discussed in http://www.cmake.org/Bug/view.php?id=15670 the SDK for the latest Windows version may not be the proper default choice. Perhaps it should be the SDK for the host machine's version of Windows to make sure we don't use APIs that cannot run on the current machine. IIRC this is the default on OS X with CMAKE_OSX_SYSROOT. Unlike CMAKE_OSX_SYSROOT, which is used by all generators on OS X, the WindowsTargetPlatformVersion value is something only for the VS IDE generators. In any command-line build we expect the INCLUDE/LIB environment variables to already be set to the proper location. Therefore we need to define a way to set the WindowsTargetPlatformVersion only for VS IDE generators since they generate the environment in which to run the toolchain. CMAKE_GENERATOR_TOOLSET and CMAKE_GENERATOR_PLATFORM are existing options with generator-specific behavior. For VS they set <PlatformToolset> and <Platform>, respectively. There is quite a bit of C++-side infrastructure to propagate these values to all the right places (and honor cmake -T and -A options on the command line). I'd rather not have something quite so heavyweight for WindowsTargetPlatformVersion because it is a pretty narrow case that should not need a dedicated command-line option and won't be meaningful to other generators. We could simply define a CMAKE_VS_TARGET_PLATFORM_VERSION variable that is used to initialize VS_TARGET_PLATFORM_VERSION target properties (see SetPropertyDefault calls in the source). Then the generator can look just at the target property. If not set it should choose a default based on the current host version of Windows as discussed above. Then we just need to teach cmCoreTryCompile to propagate this setting. The above-linked issue also mentions that TargetFrameworkVersion may need similar infrastructure. -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
