Since commit 059c230d (VS: Explicitly default to v100 toolset in Visual
Studio 2010, 2016-07-21) the VS 2010 generator now correctly defaults to
the v100 toolset instead of no toolset. However, this broke our logic
for defaulting to the `Windows7.1SDK` toolset for 64-bit builds on VS
2010 Express. Fix the logic by ignoring the `v100` default in the case.
The `ARGC`/`ARGV#` variables in function scope hold the original
arguments with no ;-list flattening. Add a way for functions to
cleanly parse arguments that may contain `;`. This also avoids
extra copying of the arguments.
Co-Author: Brad King <brad.king@kitware.com>
The matching expression added by commit v3.5.0-rc1~33^2
(GetPrerequisites: Define api-ms-win-* files as system libraries,
2016-01-19) did not account for absolute paths to the UCRT libraries.
We already recognize absolute paths to the MSVC runtime libraries.
Do this for UCRT libraries too.
Issue: #16240
Code extracted from:
https://gitlab.kitware.com/utils/kwiml.git
at commit d564b3c71a6dcec9b1cd84afb498b14a69307780 (master).
Upstream Shortlog
-----------------
Brad King (1):
d564b3c7 Update copyright year
Richard W.M. Jones (1):
12f000d5 abi.h: Add RISC-V, a little-endian architecture.
Teach the lexer to match and return specific Fortran keywords as tokens.
Update the parser to use these instead of always using a WORD token and
then checking the text. This avoids extra string comparisons and will
allow more grammar productions to be unambiguously added later for
additional Fortran statements.
Our Fortran grammar is a bare minimum to extract dependencies.
Other statement syntax can be ignored, so simply skip to the
end of unrecognized statements. This allows some of our existing
productions to be dropped.
d28da906 cmFortranParser: Inject a newline at end-of-file when missing
8c65a501 cmFortranParser: Revise indentation style to match rest of CMake
f70c71c5 cmFortranLexer: Update to flex 2.6
e11cd31f Fortran: Warn when dependency scanning fails to parse a source file
bdc679a8 VS15: Add Visual Studio 15 generator
a8936656 VS: Update v140 flag tables from VS 15 MSBuild files
21346d3f Features: Record features for VS 15 Preview 4
Call the generator "Visual Studio 15" without any year because the
preview version of VS 15 does not provide a year in the product name.
Copy cmGlobalVisualStudio14Generator to cmGlobalVisualStudio15Generator
and update version numbers accordingly. Add the VS15 enumeration value.
Note that we do not need to add a MSVC15 variable or v150 toolset
because Visual Studio 15 comes with an updated version of the v140
toolset and remains ABI-compatible.
Teach tests VSExternalInclude, RunCMake.GeneratorPlatform, and
RunCMake.GeneratorToolset to treat VS 15 as they do VS 10-14.
Closes: #16143
If multiple ExternalData_Target_Add calls generate the same output file
then we need to avoid calling add_custom_command multiple times with
that output. This was already done within a single target by setting a
variable in the local function scope. This will not be visible in other
calls though so we need to use a directory property instead to prevent
adding a custom command multiple times for one output in a directory.
Normally it is not safe to have multiple custom commands that produce
the same output file across multiple independent targets, but since we
use atomic replacement of outputs the resulting races should not be a
problem. For the convenience of projects, tolerate this instead of
diagnosing it. In particular, we previously allowed up to two copies
of the custom command in one directory because CMake has a fallback
from MAIN_DEPENDENCY to an `<output>.rule` file.
While at it, add a note to the documentation that typically only one
external data target should be needed for a project.
Reported-by: David Manthey <david.manthey@kitware.com>
Make `CPACK_DEBIAN_PACKAGE_DESCRIPTION` fallback variable precedence
match CPackRPM behavior as much as possible. This is technically a
breaking change, but the new behavior is more consistent with
expectation anyway.
Closes: #16272
When exporting from a project (with install(EXPORT ...)), the
`<PROJECT>Targets.cmake` file contains logic for computing the
`_IMPORT_PREFIX` from its own location. This `_IMPORT_PREFIX` is then
used in the `<PROJECT>Targets-<config>.cmake` file to generate the
`IMPORTED_LOCATION_<CONFIG>`. The generation unconditionally appends a
"/" to `_IMPORT_PREFIX` before appending the rest of the path. If
`_IMPORT_PREFIX` is "/", then the `IMPORTED_LOCATION_<CONFIG>`
properties all start with exactly two leading slashes ("//").
Exactly two leading slashes is a special case in POSIX file paths, such
that its interpretation is left up to the implementation. This means
that changing the path prefix from "/" to "//" should not be allowed.
Since references to `_IMPORT_PREFIX` are always followed by a "/",
simply check the value to replace "/" with "".
Since commit 14a8d61f (cmMakefile: Port nested error logic away from
cmExecutionStatus) we fail to continue processing function and macro
bodies after non-fatal errors. A non-fatal error should not stop
foreach loops, macro bodies, nested bodies, or the outer script.
Add a test covering these cases, and revert the change to fix them.
Also revert commit 2af853de (cmMakefile: Simplify IssueMessage
implementation) because the assertion it added (which was removed by the
above commit and is restored by reverting it) is incorrect. We do have
code paths that call cmMakefile::IssueMessage with an empty execution
stack, such as in CheckForUnusedVariables's LogUnused call.
Brad King
Roger Leigh
Michael Stürmer
Kitware Robot
Daniel Pfeifer
Bill Hoffman
Raffi Enficiaud
Domen Vrankar
Ben Keller