Code extracted from:
https://github.com/pboettch/vim-cmake-syntax.git
at commit 64ff4bd793c247da5a1772fffad91378dddf03b9 (master).
Upstream Shortlog
-----------------
Patrick Boettcher (1):
64ff4bd7 break line after each high-lighting keyword
Revert commit v3.13.0-rc1~144^2 (cmake-server: Support codemodel
filegroups for INTERFACE_SOURCES, 2018-08-10). The changes activate
code paths not meant to be used with interface libraries. Another
approach will be needed to expose this information later.
This revert has to be done by hand because the code in question has been
changed somewhat since the changes were made, and was also factored out
to another source file.
Fixes: #18463
This was overlooked in the initial implementation of CMP0053. However,
an additional policy to reject it again is not worth it. Instead, add
tests and document the behavior.
Fixes: #17883
Revert commit v3.13.0-rc1~441^2 (install: Teach CODE,SCRIPT modes to
evaluate generator expressions, 2018-05-29). Unfortunately it has
been found to break existing code in a real project, e.g.
install(CODE [[
message("$<FOOBAR>")
]])
Address this regression by reverting support for the 3.13 release
series. Support can be restored later with a policy for compatibility.
Issue: #15785Fixes: #18435
CUDA Toolkit Visual Studio Integration for version 9.2 and above does
honor the `ClCompile.ProgramDataBaseFileName` field when telling `nvcc`
how to invoke `cl`. Unfortunately it does not quote paths with spaces
correctly:
-Xcompiler "... /Fd"C:\path\with space\foo.pdb" ..."
Work around this by converting the PDB location to a relative path.
Likely we could always do this, but for now make a minimal change
just for CUDA support.
Fixes: #18440
The workaround added by commit v3.12.0-rc1~227^2 (VS: Add workaround for
CUDA compiler PDB location, 2018-04-13) is not necessary on CUDA 9.2+
because the CUDA Toolkit Visual Studio Integration has fixed the
original bug and forwards the `ProgramDataBaseFileName` to the host
compiler itself. Make the workaround conditional on the CUDA version.
Issue: #18440
Code extracted from:
https://github.com/pboettch/vim-cmake-syntax.git
at commit ac1957fbccd24abc91089517f9116272825f8340 (master).
Upstream Shortlog
-----------------
Pablo Hernandez-Cerdan (1):
baf680ae Add syntax for new cmake variables
Patrick Boettcher (5):
2c9d5fda handle bracket-comments and arguments correctly
37d3bcb0 add test for bracket-comments and arguments
99b4a3d9 promote package_config_file-st to .in-file and add test
3ed26c29 update to cmake version 3.13.20181010-ga3598
ac1957fb update README
When `BISON_TARGET` is called with both
VERBOSE <extra-file> REPORT_FILE <file>
we add a custom command to copy `<file>` to `<extra-file>`. The change
in commit v3.7.1~10^2 (FindBISON: Do not rebuild every time when not
VERBOSE, 2016-11-14) incorrectly listed the extra file as an output of
the main bison invocation custom command, but it is actually produced by
the separate copy command. Fix the logic to always generate `<file>` as
an output of the bison command and `<extra-file>` as an output of the
copy command.
Fixes: #18433
The logic added by commit v3.6.0-rc1~338^2 (CMake: Extend TIMESTAMP
sub-commands with new unix time format specifier, 2016-02-16) to restore
the `TZ` environment variable does not properly handle the case in which
the variable was originally not set. Unset the variable in this case.
Fixes: #18431
Documentation added by commit 4b35dab891 (Help: Document how escape
sequences work in a regex, 2018-07-18) is only correct for backslashes
inside `[]` groups. The regex engine does interpret `\` escapes
elsewhere. Fix the docs.
Inspired-by: R2RT <artur.ryt@gmail.com>
Fixes: #18428
Modern Intel MKL packages offer 64-bit BLAS and LAPACK libraries in any
of the eight combinations of the following three binary options:
- sequential or threaded
- LP64 or ILP64
- static or shared
The modules FindBLAS and FindLAPACK did not allow full selection of
arbitrary combination; in particular, only LP64 variant was used.
The original list of possible BLA_VENDOR values related to MKL,
Intel10_64lp
Intel10_64lp_seq
is thus extended by another pair of "vendors",
Intel10_64ilp
Intel10_64ilp_seq
Depending on the selection, either "_lp64", or "_ilp64" MKL libraries
are searched for. Some comments in the two CMake modules were modified
to indicate that even though the "vendors" contain the number "10",
they also apply to all further versions of MKL.
The `optimized` and `debug` keyword items are meaningful only to
the `target_link_libraries` command and have no meaning when
produced by a generator expression. State this explicitly.
Also recommend use of a quoted argument when the genex itself
may contain a semicolon.
Fixes: #18424
If a project() call does not have DESCRIPTION or HOMEPAGE_URL
options, it must still set the relevant variables or else those variables will
inherit values from an earlier project() call. That is inconsistent with how
VERSION is handled and is likely to be unexpected. The docs were also
ambiguous about what should happen in such cases.
Brad King