Entries of the `CPATH` environment variable are implicitly searched as
include directories by some C/C++ compilers. Since commit 5990ecb741
(Compute implicit include directories from compiler output, 2018-12-07,
v3.14.0-rc1~108^2) these entries are detected by CMake and included in
the `CMAKE_{C,CXX}_IMPLICIT_INCLUDE_DIRECTORIES` variables.
However, we should not exclude them from explicit specification via `-I`
or particularly `-isystem` because they are meant as user-specified
include directories that can be re-ordered without breaking compiler
builtin headers. In particular, we need explicit requests via
`include_directories` with the `SYSTEM` option to result in `-isystem`
so that third-party headers do not produce warnings.
Co-Author: Ben Boeckel <ben.boeckel@kitware.com>
Fixes: #19291
Our practice of closing MRs temporarily while discussion
takes place in a separate issue isn't always well understood
by MR authors. Expiring a MR seems to be better understood,
but making it clear that it is also a temporary state is helpful.
* Deprecation removals previously specific to MSVC/Intel now also used
by clang
* String literals were assigned to non const pointers. These are stored
in mutable arrays now
* An implicit function pointer to pointer conversion is a Microsoft
extension warning is suppressed by an explicit reinterpret_cast
* The MSVC specific deprecation macro for jsoncpp was moved after the
clang macro to avoid redefinition warnings. This is consistent with
how jsoncpp fixed the issue in 36d8cfd7
Code extracted from:
https://github.com/pboettch/vim-cmake-syntax.git
at commit c42ede9f70e53a69f98e5bc5df16f834937dd37c (master).
Upstream Shortlog
-----------------
Patrick Boettcher (6):
4e657a05 update to cmake version 3.13.20181220-g0495c
b0ada6e2 add <LANG>-replacing in variables.
60654a65 Update keywords for version 3.14.20190402-g56ae2
33e512bd format brace-encapsulated variables (varname from var)
a3628ebb fix keywords of generator-expressions wrongly colored in simple arguments
c42ede9f update to cmake version 3.14.20190529-g067a4f
74829f01b1 Help: Add notes for topic 'clang-gnulike-support'
19669abe1d Tests: handle string escaping differences with NMake+clang
a2a90f41e3 Tests: require C++14 for the Tutorial
4819ff9647 Tests: fix failures with gnu mode clang on windows
26af0b25e7 cmake: use correct stack size with gnu mode clang on windows
d44c0db0b2 clang: setup correct configuration in gnu mode
b7d5ef23e9 cmGlobalNinjaGenerator: use gnu compatible paths with clang in gnu mode
3d0210d8dc binutils: add the llvm-* variants to the tool lists.
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Francesco Bertolaccini <francesco@bertolaccini.dev>
Acked-by: Stanislav Ershov <digital.stream.of.mind@gmail.com>
Acked-by: Saleem Abdulrasool <compnerd@compnerd.org>
Merge-request: !2992
Instead of passing multiple strings to the `WriteRule` and `AddRule` methods
of `cmGlobalNinjaGenerator`, pass only a `cmNinjaRule` instance reference,
that is set up beforehand.
Adapt calls to `WriteRule` and `AddRule` in multiple places.
Drop the sentence added by commit 5a5a1d90f0 (Help: FindThreads not
needed with modern C++., 2019-01-09, v3.14.0-rc1~186^2) about not
needing the module with modern C++. The module is often still needed.
Fixes: #19297
`CMAKE_AUTOMOC_RELAXED_MODE` was added for backwards compatibility with KDE 4,
which had its last release in 2014. It does not offer additional features
but complicates the `AUTOMOC` code and dependency computation considerably.
Projects that use `CMAKE_AUTOMOC_RELAXED_MODE` functionality always got
extensive warnings during builds and tips on how to convert to regular mode,
which is trivial (see commit e474dcb231, CMake 2.8.7).
It's time to consider this feature deprecated and issue a warning at
configuration time as well.
This adds a configuration time deprecation `AUTHOR_WARNING` for
`CMAKE_AUTOMOC_RELAXED_MODE`.
Swift's driver will invoke the C++ driver (`clang++`) to invoke the
linker. Additionally, it will configure the command line to deal with
the linkage runtime support object (`swiftrt.o` or `swiftrt.obj`) to be
added at the right time (similar to C/C++). Since it indirects through
`clang++` it will properly setup the linker invocation for C++ and C as
well. This should permit the correct linker driver to be invoked in
multi-language projects.
Closes#19299
Brad King