To get rc defines to work in the VS10 IDE requires \" when
constructing PreprocessorDefinitions strings. This is different
than defines for cl.
Also, per-file rc defines were not being generated. Fix that, too.
During a try_compile cmGlobalGenerator::EnableLanguage uses results from
the outer project. Reject attempts to enable languages in the test
project that are not "ready" in the outer project. Mark a language as
"ready" when all its information has been loaded and we are ready to
generate build rules.
This also avoids infinite recursion introduced by commit 295b5b60 (Honor
CMAKE_USER_MAKE_RULES_OVERRIDE in try_compile, 2010-06-29) for projects
that set CMAKE_USER_MAKE_RULES_OVERRIDE to a file that uses try_compile.
The file is loaded along with the information for a given langauge so
the language is not yet "ready".
If CMAKE_MAKE_PROGRAM is set to devenv, then GenerateBuildCommand
uses it just like we used to do for VS8 and VS9. Otherwise, it
still uses MSBuild.
This will let us run the CMake test suite through devenv and make
sure all the solution and project files we generate are load-able
and build-able by the VS 2010 IDE, not just MSBuild.
Inspired-By: Robert Lenhardt
WriteCLSources should skip source files with "obj" extensions
since WriteObjSources has already written them into the vcxproj
file. Likewise, WriteGroupSources should skip source files with
"obj" extensions to avoid receiving "item ... already exists under
the filter" project-load-time error messages from Visual Studio.
If the source-file form of try_compile is given a file name with
multiple '.' characters such as "a.b.c" use only the shortest extension
to check the language. This is the expected behavior and is consistent
with normal language extension determination in the method
cmSourceFileLocation::UpdateExtension.
Set CMAKE_RUNTIME_OUTPUT_DIRECTORY explicitly in try_compile projects so
that the COPY_FILE feature knows where to look. This makes the feature
robust against CMAKE_USER_MAKE_RULES_OVERRIDE files that set variables
like CMAKE_RUNTIME_OUTPUT_DIRECTORY or EXECUTABLE_OUTPUT_PATH.
This variable was introduced to help authors override CMake's default
platform information before any of it is cached. State this clearly in
the documentation. Explicitly discourage use for other purposes.
Previously this was used only in multi-configuration generators to
choose the configuration of try_compile and try_run at their build time.
Teach CMake to honor the variable in single-configuration generators as
the CMAKE_BUILD_TYPE.
Factor out generation of SccProjectName, SccLocalPath, and SccProvider
from cmLocalVisualStudio7Generator::WriteProjectStart and call it from
cmLocalVisualStudio7Generator::WriteProjectStartFortran too.
On Windows platforms source files may contain '\' in include directives:
#include "a\b.h"
Normalize these while scanning to use forward slashes. CMake will
convert from forward slashes to the direction preferred by the native
build tools when writing the path to 'depend.make' files.
Show "<variable|string>" explicitly in if() case documentation whenever
auto-dereferencing occurs. Reference its presence from the explanation
at the bottom.
The signature of get_test_property uses argument order
test property VAR
not
test VAR property
Also document the actual behavior when the property is not found.
Some values simply cannot be escaped properly in all contexts for all
native build tools. Document known limitations after the disclaimer
that states so.
Previously the error message for code like
add_executable(myexe does_not_exist/mysrc.c)
mentioned only that "mysrc.c" is not found. Report the directory too.
Remove the example explained by the misleading phrase "CMake will treat
it as if you wrote". This was originally added by commit a73071ca
(modified the if command to address bug 9123 some, 2009-06-12). Later
related information elsewhere in the documentation was corrected and
made precise by commit cb185d93 (Fix if() command and CMP0012 OLD/NEW
behavior, 2009-10-27) but the misleading example was not corrected.
Replace the example with a correct one that more directly covers the
case that typically surprises newcomers. Avoid recommending a "correct"
way to write code because this behavior is always specific to each case.
Also update the main documentation of the behavior to be more explicit.
