8f68bcad8f Tests: Add cases verifying flag ordering rules
ccc83ce162 Help: Document order of flags from CMAKE_<LANG>_FLAGS and COMPILE_OPTIONS
df79fe055b Help: Remove incorrect "versionadded" for CMAKE_<LANG>_FLAGS_<CONFIG>
c48d2d8480 VS: Place per-source preprocessor definitions after target-wide ones
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6187
Commit e71c4f7729 (CMAKE_CFG_INTDIR: Formally deprecate in favor of
$<CONFIG>, 2021-05-27) only updated the docs for CMAKE_CFG_INTDIR
itself, but other parts of the docs still used it. Update the other places
to avoid referring to the now-deprecated variable.
When the VS 2010+ generators were first implemented in commit 7491f52992
(ENH: first pass at VS 10, can bootstrap CMake, but many tests still
fail, 2009-06-25, v2.8.0~546), the per-source preprocessor definitions
were placed before target-wide preprocessor definitions for consistency
with the behavior of VS 9 2008 and below. However, those generators
are not used much anymore. Instead prefer consistency with the order
used by the Ninja and Makefile generators.
3941555d93 target_link_libraries: Place $<TARGET_OBJECTS> before libraries
f530b3a267 OpenWatcom: Add infrastructure to link to object files
8a4ca110e4 cmComputeLinkInformation: Improve type safety of item IsPath member
83ad066ed1 cmComputeTargetDepends: Factor out helper to add object library dependency
7f506b95a7 cmGeneratorTarget: Refactor link item lookup
96809a8541 cmGeneratorTarget: Give temporary link impl item an explicit name
ddffbb8adb cmMakefile: Register explicit object sources more efficiently
18e42d3e63 cmGeneratorExpressionNode: Constify local variable
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6166
OUTPUT variant with a TARGET given to allow resolving target-based generator
expressions wouldn't work because OUTPUT is resolved before generator targets
are created, i.e. FindGeneratorTargetToUse() returns nullptr.
This is a known limitation, see #21364.
Implements #21336.
Linkers always use object files explicitly specified on the command line
regardless of where they appear. Move them to the front of the list of
linked libraries in so that symbols required by the object files can be
resolved by any library.
Issue: #22149
The Ninja generator traditionally referenced source files and include
directories using paths relative to the build directory if they could be
expressed without a `../` sequence that leaves the build and source
directories. For example, when using a `build/` directory inside the
source tree, sources would be compiled as `-c ../src.c` and include
directories would be referenced as `-I ../include`. This approach
matches the traditional Ninja convention of using relative paths
whenever possible, but has undesirable side effects such as:
* Compiler diagnostic messages may not use absolute paths, making it
harder for IDEs/editors to find the referenced sources or headers.
* Debug symbols may not use absolute paths, making it harder for
debuggers to find the referenced sources or headers.
* Different results depending on the path to the build tree relative
to the source tree.
* Inconsistent with the Makefile generators, which use absolute paths.
Switch to always using absolute paths to reference source files and
include directories on compiler command lines. While alternative
solutions for diagnostic messages and debug symbols may exist with
specific tooling, this is the simplest and most consistent approach.
Note that a previous attempt to do this in commit 955c2a630a (Ninja: Use
full path for all source files, 2016-08-05, v3.7.0-rc1~275^2) was
reverted by commit 666ad1df2d (Revert "Ninja: Use full path for all
source files", 2017-02-24, v3.8.0-rc2~9^2) due to problems hooking up
depfile dependencies on generated files. This time, the changes in
commit 2725ecff38 (Ninja: Handle depfiles with absolute paths to
generated files, 2021-05-19) should avoid those problems.
Fixes: #13894, #17450
The `Vulkan::Headers` target complements existing Vulkan::Vulkan target.
It is the same except it omits the Vulkan library which supports
applications that loads the Vulkan library in at runtime.
The `Vulkan::glslangValidator` target provides the glslangValidator
executable which is the tool for converting between shader languages
(GLSL, SPIR-V, etc.).
The new variable allows projects to define custom key=value pairs of
variables to be set in CPack cmake_install.cmake script invocations.
This allows install(SCRIPT|CODE) to be parameterized at runtime.
0a0a0f8a74 cmMessenger: Color messages to terminal by type
bceb8e2ed2 cmMessenger: Pass title inside a metadata structure
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6105
In a per-component installation the generated installation scripts
are invoked once for each component.
Per default custom installation script code added by install(CODE|SCRIPT)
only runs for one specific component in this context.
The new ALL_COMPONENTS option allows custom script code to be run once
for each component being installed.
Comments at the bottom of the docs for add_compile_options() and
target_compile_options() recommend using other commands if setting
compiler definitions. Change the examples we use for the SHELL:
functionality to use -option instead of -D so that we don't violate our
own recommendations. This also makes the examples more
appropriate for use with link options as well.
Tweak the wording to not specify the type of option being discussed.
This will already be clear from the page the text is included into and
it avoids naming unrelated option types for the given page.
These fields are specified by our `P1689r3` paper, but are not actually
needed. The dependencies of the scanning results themselves can be
captured via normal depfile logic. Avoid saving this possibly-large
information in the scanning results. It is not needed by later steps.
