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.
Previously the Xcode generator would rerun CMake only if input file
dependencies in the top-level directory changed. Teach it to depend on
input files from all directories. Other generators already do this.
Reported-by: Johan Björk <phb@spotify.com>
Explicitly state up front that the source-file form of the command links
an executable and expects a 'main' to be defined. While at it, update
the command signature documentation to use a syntax more consistent with
other commands. Also tweak some wording.
ce28737 Remove usage of CMAKE_CURRENT_LIST_DIR now that we have CMP0017
7db8db5 Improve documentation and messages for the new CMP0017
db44848 Prefer files from CMAKE_ROOT when including from CMAKE_ROOT
1e69c6f Merge branch 'user-policy-defaults' into policy-CMP0017
65a0a2a Merge branch 'include-command-whitespace' into policy-CMP0017
e33cbda VSMidl Test: Use correct include_directories with VS6 (#11461)
262da91 Prohibit space in HOME value for VSMidl test.
13caaa3 VS10: Finish Midl support (#11461)
Although the LOCATION property is for compatibility with CMake 2.4, the
LOCATION_<CONFIG> property is modern. However, if a project reads it
and sets location-altering properties later the behavior is undefined.
See parent commit for details.
Reading the LOCATION target property currently locks down the result and
ignores any later changes to properties that affect it. This may or may
not be expected and may or may not be the behavior in earlier versions
of CMake. The property is documented as provided only for compatibility
with CMake 2.4 and alternative interfaces are now available for all
originally envisioned use cases. We want to discourage its use without
outright deprecating it. Add documentation to explicitly state that
reading the property before other properties are set is undefined.
Previously, only strings containing "http:" qualified as
URLs when found in CPACK_NSIS_MENU_LINKS. Now, we use a
regex to detect strings beginning with any of the following:
ftp://
ftps://
http://
https://
news://
mailto:
This commit also moves the caller of CreateMenuLinks outside
the "if (cpackPackageExecutables)" block, allowing clients to
use CPACK_NSIS_MENU_LINKS without also having CPACK_PACKAGE_EXECUTABLES
defined. That bit of this commit fixes the remainder of the
issue described in http://public.kitware.com/Bug/view.php?id=7828
Also, added a set(CPACK_NSIS_MENU_LINKS ...) to the CPackComponents
test to enable verifying that all of this actually works.
CMake fails to find any registry paths on Windows 2000: according to regmon
it fails with an access denied error. I double checked all the access rights
and they are fine. After checking the access modes on MSDN I found that it
says KEY_WOW64_32KEY / KEY_WOW64_64KEY are not supported on Windows 2000.
CMake does not check if the current system supports Wow64 before applying
these flags.
This commit adds a check for IsWow64Process in kernel32.dll before adding
these flags.
Author: Axel Gembe <ago@bastart.eu.org>
Signed-off-by: Axel Gembe <ago@bastart.eu.org>
Brad King
KWSys Robot
David Cole
Chuck Atkins
Bill Hoffman