Improve wording in our advice about how to call both of these modules.

Since commit v3.4.2~2^2 (VS: Fix VS 2015 .vcxproj file value for
GenerateDebugInformation, 2016-01-08) we generate invalid project
files for the v110 and v120 toolsets.  VS complains:

    C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(639,9):
    error MSB4030: "Debug" is an invalid value for the "GenerateDebugInformation" parameter of
    the "Link" task. The "GenerateDebugInformation" parameter is of type "System.Boolean".

This reveals that our VS flag map selection should be based on the
toolset instead of the version of VS.  However, that will be a
non-trivial change so for now fix this particular use case by
hard-coding a correction to the flag map.

Reported-by: Gregor Jasny <gjasny@googlemail.com>

Since commit v3.5.0-rc1~47^2 (FindCUDA: Support special characters in
path, 2016-01-15) our add_custom_command calls use VERBATIM so that
CMake will automatically quote special characters correctly.  However,
this breaks the special `$(VCInstallDir)` placeholder used with Visual
Studio generators.  Since we do not support preservation of such
placeholders with VERBATIM (see issue #15001) we must fall back to not
using VERBATIM when the placeholder is used.

A better fix would be to stop using `$(VCInstallDir)` and use the value
of `CMAKE_${CUDA_C_OR_CXX}_COMPILER` instead, but that will require
additional semantic and documentation changes.  For now simply fix the
regression with the above approach.

Reported-by: Stephen Sorley <Stephen.Sorley@jhuapl.edu>

In commit v3.5.0-rc1~43^2 (Fix export of STATIC library PRIVATE
dependencies with CMP0022 NEW, 2016-01-15) we taught
target_link_libraries to generate `$<LINK_ONLY:$<TARGET_NAME:dep>>` in
INTERFACE_LINK_LIBRARIES instead of `$<LINK_ONLY:dep>` so that `dep` can
be recognized as a target name and updated during export.  However, this
approach does not work when `dep` is just a plain library name and not a
target because `$<TARGET_NAME:...>` requires the name of a reachable
target.

Since we do not know during target_link_libraries whether the name will
correspond to a reachable target or not, we cannot inject the
`$<TARGET_NAME:...>` expression.  Revert this change and solve the
original problem instead by teaching the export logic to recognize and
update target names directly in `$<LINK_ONLY:...>` expressions.

Reported-by: Ben Boeckel <ben.boeckel@kitware.com>

The option does not actually participate in argument groups like the
others because it does not actually install anything.  Fix the order
in the documentation accordingly.

Reported-by: Daniel Wirtz <daniel.wirtz@simtech.uni-stuttgart.de>

We deprecated this module in commit v3.5.0-rc1~295^2
(CMakeForceCompiler: Deprecate this module and its macros, 2015-10-19)
in order to determine whether anyone still has use cases that require
it.  Indeed we still need to provide a way to work with toolchains that
cannot link binaries without special flags.  Remove the deprecation
warnings until we can provide an alternative to the module for this use
case.

Dimitar authored 9 years ago and Brad King committed 9 years ago

The re-implementation in commit v3.5.0-rc1~116^2~1 (CMakeParseArguments:
replace by native cmake_parse_arguments command, 2015-12-05) introduced
a regression when parsing the ARGN arguments with cmake_parse_arguments.
The original implementation used

    foreach(currentArg ${ARGN})

to iterate over input arguments.  This flattened ;-lists within the
arguments whether they were quoted or not.  Fix our new implementation
to preserve this behavior and add a test case to cover it.

Signed-off-by: Dimitar Yordanov <dimitar.yordanov@sap.com>
Signed-off-by: Matthias Maennich <matthias.maennich@sap.com>

Refactoring in commit v3.3.0-rc1~29^2~1 (cmState: Host some state from
the cmGlobalGenerator, 2015-05-24) moved storage of some generator
traits over to cmState.  However, it accidentally removed initialization
of the values from the cmGlobalGenerator constructor.  This is needed
because generator subclasses update the settings in their constructors.
Since a single cmState instance is shared across multiple build trees by
cmake-gui, initializing the values in its constructor is not enough.
Fix this by restoring the needed initializations to the
cmGlobalGenerator constructor.

The fix in commit v3.5.0-rc1~84^2 (Xcode: Escape all backslashes in
strings, 2015-12-27) is a change in behavior that can break existing
projects that worked around the inconsistency with other generators.
Add a release note to call attention to this change in behavior.

This version introduced CURLE_NOT_BUILT_IN which we have used since
commit v3.4.0-rc1~211^2~4 (cmCurl: Tolerate lack of CURLOPT_CAPATH
support, 2015-08-12).  For older versions, just define the name to the
then-unused error code so that we can compile.

Nils Gladitz authored 9 years ago and Brad King committed 9 years ago

Use a custom action to look for Uninstall.exe in the user
selected installation prefix.

Its presence indicates a previous NSIS installation.
Inform the user and request manual resolution of the issue.

In commit v3.5.0-rc1~272^2~6 (cmGlobalGenerator: Add FindGeneratorTarget
API, 2015-10-25) a lookup was implemented via linear search.  Replace it
with an efficient data structure.

Suggested-by: Stephen Kelly <steveire@gmail.com>

Refactoring in commit v3.5.0-rc1~272^2~13 (cmGlobalGenerator: Remove
direct storage of targets, 2015-10-25) replaced an efficient data
structure mapping from target name to cmTarget instance with a linear
search.  Lookups through cmGlobalGenerator::FindTarget are done a lot.
Restore the efficient mapping structure with a name indicating its
purpose.

Reported-by: Bartosz Kosiorek <gang65@poczta.onet.pl>

The EXPORT-OldIFace test case uses install(TARGETS) and so generates a
warning:

 CMake Warning in CMakeLists.txt:
   WARNING: Target "foo" has runtime paths which cannot be changed during
   install.  To change runtime paths, OS X version 10.6 or newer is required.
   Therefore, runtime paths will not be changed when installing.
   CMAKE_BUILD_WITH_INSTALL_RPATH may be used to work around this limitation.

Set CMAKE_BUILD_WITH_INSTALL_RPATH to avoid the warning since we do not
need to run the binaries from the build tree anyway.

Horst Kronstorfer authored 9 years ago and Brad King committed 9 years ago

Implementation indicates that at least two components of VERSION must
be specified (see Source/cmCMakeMinimumRequired.cxx.) Therefore the
minor version is not optional.

Paul Wilkinson authored 9 years ago and Brad King committed 9 years ago

The COMPATIBLE_INTERFACE_NUMBER_MAX example now sets
INTERFACE_CONTAINER_SIZE_REQUIRED on lib1Version2 and lib1Version3.
Previously set it on lib1Version2 twice and never on lib1Version3.