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.
Implement support for multiarch include directories as specified here:
https://wiki.ubuntu.com/MultiarchCross
Generalize the multiarch feature added in commit b41ad3b3 (Teach
find_(library|package) about Linux multiarch, 2011-06-08) to the
find_path and find_file commands. Teach them to search
<prefix>/include/<arch> whenever they would search <prefix>/include.
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.
This is for consistency throughout cmake. The cmsys version exists
becaues uses of auto_ptr types as return types does not work with
some implementations in ancient compilers.
Following from the discussion here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3615/focus=5170
(Re: Generator expressisons in target properties, 26 Oct 12:10)
we can't split cmTarget API for linking into cmGeneratorTarget. In
the future we will probably also need to move the include and compile
definitions API back to cmTarget so that it can be used by export().