9a8d758c Help: Document language standard meta-features
df252db1 Features: Test cycle diagnostic with language standard meta-feature
6d5fb0e0 Features: Test feature propagation with language standard meta-feature
a34b98a8 WCDH: Ignore language standard meta-features
b0996a3f Features: Add meta-features requesting awareness of a particular standard
8b6cc251 Features: Centralize per-compiler recording macros
2d23f7b2 Features: Do not record features on MSVC < 2010
The switch to use UTF-8 encoding has been defaulted to on for quite some
time since commit v3.2.0-rc1~116^2 (Encoding: Switch to use UTF-8
internally by default on Windows, 2014-12-26).
A common use case of `target_compile_features` is simply to specify that
the compiler should be run in a mode that is aware of e.g. C++11. Some
projects simply specify a particular C++11-only feature to request this.
Provide a first-class way to do this by naming features after the
corresponding language standard. Record them as always available in the
corresponding standard level so that requesting them always ensures that
standard (or higher) is used.
Refactoring in commit b29425f7 (cmLocalGenerator: Populate a container
of mappings for replacements, 2016-10-09) broke substitution of this
placeholder by storing the wrong key in the new replacement map.
Use the proper key, `CMAKE_<LANG>_COMPILER_ARG1`.
f648b9be Tests: Check that CROSSCOMPILING_EMULATOR is not used on imported targets
e7480d67 Fix custom command target substitution with CROSSCOMPILING_EMULATOR
9a58517d Tests: Add case for Xcode per-config per-source COMPILE_FLAGS diagnostic
1e4bb358 Add generator expression support to per-source COMPILE_FLAGS
In commit v3.6.0-rc1~88^2 (CustomCommandGenerator: Add support for
CROSSCOMPILING_EMULATOR, 2016-05-04) logic was introduced to substitute
a target's `CROSSCOMPILING_EMULATOR` for argv0 in a custom command.
However, it broke the case when the argv0 was a target name and now
fails to expand the target name to its location at the same time as
inserting the emulator. Fix the latter case.
Inspired-by: Brian Maher <brian@brimworks.com>
Closes: #16288
This allows users to specify different genex-based compile flags for
each file in a target, e.g. compiling just a single file with `Od/Ox` in
release builds on Visual Studio.
Catch more problematic input during handshake and report failure.
These were caught before when trying to configure, but it is way better
to get these reports early.
Refactoring in commit 584ab528 (VS: Add internal API to get platform
toolset as string, 2016-10-18) accidentally changed the semantics of the
original `cmGlobalVisualStudio10Generator::GetPlatformToolset`
implementation to return a pointer to an empty string instead of
`nullptr` when no toolset is configured. This broke cases that tested
for `nullptr` to detect the lack of any specific toolset, such as the
call in `Find64BitTools`. Restore the `nullptr` return in this case.
Use KWSys ConsoleBuf to replace the `streambuf` on `std::cout` and
`std::cerr` so that process output can be encoded correctly for display
in a Windows console.
69fc7bf8 VS: Choose flag map based on the toolset name
e2ed9a70 VS: Move toolset flag table lookup to global generator
584ab528 VS: Add internal API to get platform toolset as string
MSBuild interprets the `.vcxproj` content based on the `PlatformToolset`
setting, so our reverse mapping needs to be based on that setting too.
For VS 2010 and above, choose the flag map to match the toolset name
rather than the generator VS version.
Issue: #16153
87cc9bfc Merge branch 'backport-ninja-subdir-binary-dir' into ninja-subdir-binary-dir
e983bd32 Ninja: Use binary dir for `$subdir/all` targets
42db2ebc Ninja: Use binary dir for `$subdir/all` targets
