These tests were not running properly on Visual Studio or
Xcode dashboards before this commit because of the "Debug"
or "Release" sub-directory. The scripts already have
CMAKE_CPACK_COMMAND since the correct CMake executable is
used to run the scripts, so just use that, rather than
passing down an incorrect path to the CPack executable.
3a1006e VS: Added "Deploy" at project configuration for WindowsCE targets
40c36c9 VS: Make DetermineCompilerId working with WinCE too
038df9e VS: Allow setting the name of the target platform
6fe4fcb VS: Add parser for WCE.VCPlatform.config to read WinCE platforms
2118a20 VS: Support setting correct subsystem and entry point for WinCE
6920fed VS: Change variable type of Name from const char* to string
102521b VS: Change variable type of ArchitectureId from const char* to string
332dc09 VS: Add static method to get the base of the registry
d41d4d3 VS: Add CMAKE_VS_PLATFORM_NAME definition to cmMakefile
14861f8 VS: Remove TargetMachine for linker when checking compiler id
0bbae6f Revert "Move GetLinkInformation to cmGeneratorTarget"
d5cf644 Split link information processing into two steps.
d8a59ea Port cmGeneratorExpression to cmTarget from cmGeneratorTarget.
Add a dummy mainCRTStartup() function, since the linker searches for
it instead of main() and set the CMAKE_SYSTEM_* variables depending
on the MSVC_C_ARCHITECTURE_ID and CMAKE_VS_WINCE_VERSION variables.
Parse the WCE.VCPlatform.config file, which contains the installed
WindowsCE SDKs in XML format, and add possibility to generate
Visual Studio generators for them.
When adding more platforms to the Visual Studio generators a simple
regular expressing can not handle all cases anymore. This new
define holds the name of the Visual Studio target platform.
Modern apps that use multiple threads do NOT want 10 Megabytes of RAM
per thread being used for each thread's stack... Just leave off the
/STACK: argument, and let the compiler use a reasonable default value
for the stack size.
If existing single-threaded apps require the /STACK: argument because
they do need a very large stack size, they can add the flag in their
own CMakeLists files.
add_custom_command can have empty DEPENDS arguments, which
was triggering invalid makefile generation for the NMake
Makefiles generator. We were mistakenly emitting the build
directory appended with "/" plus the empty string... which
was then translated to a string ending in \" in build.make...
which nmake choked on.
The solution is not to emit any dependency when the input
DEPENDS is the empty string. Return early from GetRealDependency
in this empty input case.