The CMAKE_SYSTEM_NAME is "CYGWIN", but we also define a variable
named "CYGWIN" to "1". Avoid allowing if() to expand the "CYGWIN"
string as a variable.
Call SetSystemName, SetGeneratorPlatform, and SetGeneratorToolset
exactly once after reading CMakeSystem.cmake, and not again on another
call to enable_language() or project().
On Arch Linux, /lib and /lib64 are symlinks to /usr/lib. When ordering
runtime library search paths, we must not consider these to be distinct
directories. Before considering conflicts between two directories,
check that they do not have the same 'realpath'.
Inspired-by: Myles English <mylesenglish@gmail.com>
The ctest_configure command already reads the CTEST_CMAKE_GENERATOR
variable to get the value for the cmake -G option. Read new variable
CTEST_CMAKE_GENERATOR_PLATFORM to pass on as CMAKE_GENERATOR_PLATFORM.
The "ctest --build-and-test" mode already has "--build-generator" to
specify the -G option to CMake. Add a "--build-generator-platform" option
to specify a value to pass on as CMAKE_GENERATOR_PLATFORM.
For VS generator names that do not specify the platform name, read
CMAKE_GENERATOR_PLATFORM to get it.
Extend the RunCMake.GeneratorPlatform test with a case covering
use of the x64 platform when the test generator is a Visual Studio
generator whose name does not specify a platform.
Reject the option by default. It will be implemented on a per-generator
basis. Pass the setting into try_compile project generation. Add cache
entry CMAKE_GENERATOR_PLATFORM and associated variable documentation to
hold the value persistently.
Add a RunCMake.GeneratorPlatform test to cover basic use cases for the
option. Verify that CMAKE_GENERATOR_PLATFORM is empty by default, and
that it is rejected when the generator does not support a user setting.
Rename the 'PlatformName' member to 'DefaultPlatformName' and make
sure it is only read through a 'GetPlatformName()' call. This will
allow non-default names to be chosen later.
Move handling of an empty toolset name into the implementation of the
method. This simplifies the VS 10 implementation of default toolset
selection because it has one code path that is always called.
Xcode requires a separate PBXFileReference for each target source group
that references a source file. Xcode 6 now diagnoses re-use of the same
PBXFileReference from multiple source groups. Add the referencing
target name to our internal map key so we use a per-target reference.
39fefde2 VS: Add test case for Windows Phone and Windows Store
89da8465 MSVC: Define 'WIN32' for Windows Store and Windows Phone
ed7f085f Help: Add notes for topic 'vs-windows-apps'
dd11ae8f VS: Do not compile C sources as WinRT (#15100)
b8e40538 VS: Mark Windows Phone and Store targets as App Containers
0432f062 VS: Always ignore ole32 on Windows Phone 8.0
e6ff2f8b VS: Generate Windows Metadata for WinRT components
ee48f4c7 VS: Generate Windows Phone and Windows Store projects as Unicode
cb1aceed VS: Add VS_WINRT_COMPONENT property to enable CompileAsWinRT
401269e4 VS: Handle .pfx files explicitly in generator
23782171 VS: Handle AppxManifest sources explicitly in generator
bc373c6d VS: Set Window Phone/Store app type in CMake-generated targets
d89b2889 VS: Mark CMake-generated targets as Utility in .vcxproj files
03ad8f28 CMakeDetermineCompilerABI: Link with standard libraries on MSVC
The MSVC /ZW flag is valid only for C++ sources. Whenever we enable
CompileAsWinRT for the whole target, disable it for all C sources.
Update the documentation of VS_WINRT_COMPONENT to drop the statement
about undefined behavior for non-C++ sources, because it is now
defined as expected.
* Add AppContainerApplication to non-UTILITY targets
* Generate app manifest and related files if project does not provide them.
Place them in a per-target directory to avoid clashes.
* Mark WinRT components with WinMDAssembly
* Import Windows Phone 8.0 targets in .vcxproj files when necessary,
and reference platform.winmd.
Inspired-by: Paul Annetts <paul@lightunobscured.com>
