Ninja: Since commit 2d85779126 (Ninja: Account for explicit target
dependencies via CODEGEN, 2026-09-15, v4.5.0-rc1~162^2), a directory's
codegen phony depends on the full build of every add_dependencies
target (which caused their non-CODEGEN commands to run). Instead,
depend only on those targets' CODEGEN outputs, and follow their own
codegen dependencies in turn.
Makefiles: Since commit 197cb419d1 (add_custom_command: Add CODEGEN
support, 2024-05-27, v3.31.0-rc1~394^2), a target's `<target>/codegen`
rule used to depend on `<dep>/all` for every add_dependencies target,
which fully built them. Instead, depend on `<dep>/codegen`, except when
the target has CODEGEN commands of its own, in which case it should
still depend on `<dep>/all` as the commands may need the dependency's
outputs.
Shape up the prior `no-codegen` test case, which wasn't verifying much
of anything.
Fixes: #28205
This was missed in the change that added imported targets to the
file API replies, b626843d71 (fileAPI: Output all INTERFACE and
IMPORTED targets, 2025-09-13). The release notes and file API schema
did get the update to mention it, only the description of the `type`
field in the file API docs was missed.
Enable test preparation targets by default. Add (better named)
`CMAKE_SKIP_TEST_PREP_TARGETS` variable to control generation of the
same, mirroring `CMAKE_SKIP_INSTALL_PREP_TARGETS`. Remove support for
old `CMAKE_TEST_BUILD_DEPENDS` variable. Update and improve
documentation.
This improves consistency between test and install preparation targets.
It also modifies the descriptions of preparation targets in the
documentation of generators which support them to be consistent.
(Previously, each generator described preparation targets in a manner
unique to each generator.)
Fixes: #28050
It has been around since CMake 2.6.3 for generated install scripts but
was never documented. Added a test for the result too, since nothing
checked it before.
Fixes: #28154
This had already been factored out to `GENEX_NOTE.rst`, but wasn't
applied very widely. Consolidate the language to consistently spell out
(a) the reference to `cmake-buildsystem(7)` and (b) the prose 'with the
syntax "$<...>"'.
To accompany the change, modify cmRST to override redefinitions of
substitutions within a single context instead of appending. Otherwise,
with the new note files, `cmake --help-*` prints repeated fragments
when it collates all scopes of a given field (e.g., all
`prop_*/COMPILE_OPTIONS.rst` from
`cmake --help-property COMPILE_OPTIONS`).
Add a `BUILD_DEPENDS` option to multiple `install` command signatures
for projects to specify dependencies which CMake cannot infer.
Co-authored-by: Tyler Yankee <tyler.yankee@kitware.com>
Closes: #27643
Extend the `install_prep/<component>` and `install_prep/all` targets to
the FASTBuild generator.
Co-authored-by: Tyler Yankee <tyler.yankee@kitware.com>
Issue: #27643
Extend the `install_prep/<component>` and `install_prep/all` targets to
the Makefile generators.
Some differences compared to the implementation for Ninja:
* A Makefile rule name cannot contain `:`, so components whose names
contain one get no preparation target.
* A top-level rule cannot build an individual custom command output, so
a generated file to be installed is prepared by building the target
that owns its custom command.
* When a target must be relinked before installation, its `preinstall`
rule is built after its `all` rule.
* Where the make tool matches target names case-insensitively,
components whose names differ only in case share a preparation
target, as done for `test_prep/`.
Co-authored-by: Tyler Yankee <tyler.yankee@kitware.com>
Issue: #27643
Add `install_prep/<component>` convenience targets to the Ninja
generators to build dependencies of install components, and
`install_prep/all` to build the dependencies of all install components.
This is similar in flavor to commit ba6b6fbc24 (Ninja: Add Build
Dependencies for Tests, 2026-04-07), but here for the install command.
Co-authored-by: Tyler Yankee <tyler.yankee@kitware.com>
Issue: #27643
Follow-up commit 6043014d1d (source_group(): Add file set support,
2026-06-13) and commit faeeac60e8 (Add SOURCE_GROUP properties for file
set and source file, 2026-06-20).
The `qthelp` builder renders with Sphinx's `nonav` theme, so the color
scheme that `cmake.css` picks up from the `default` theme in the html
build is never generated for it. The workaround that inlines the
`@import` in `cmake.css` silently falls back to `basic.css`, which
carries layout rules only, leaving the `.qch` pages with no styling of
their own.
Supply one, generated from a single template and two palettes. Qt
Creator serves a documentation set's own `offline-dark.css` in place of
its `offline.css` or `offline-simple.css` when the Qt Creator theme is
dark, so link the stylesheet under one of those names and ship a dark
counterpart next to it. Qt Creator 20 and older substitute only for
`offline-simple.css`, and request `offline.css` instead when the theme
is light, so install the light palette under both names.
The html build is unaffected: the extra stylesheet is linked, and its
static directory is added, only under the `qthelp` tag.
Previously, add_test and discover_tests required absolute paths to
files in BUILD_DEPENDS arguments. Relax this to allow projects to
specify relative paths, which is more consistent with e.g.
add_custom_command(DEPENDS).
Tyler Yankee