Projects which ship object files as artifacts may want to control the
object names as much as possible. Support setting explicit object names
as source file properties to support such use cases.
* Fix bullet points from commit bf52fbfbc4 (instrumentation: Add Google
trace output, 2025-08-28).
* Pluralize "v1 Snippet File" where applicable.
* Wrap long lines to <80 chars where applicable.
CMake historically has forced an `objects[-<CONFIG>]/<TARGET_NAME>`
subdirectory under an `OBJECT` library installation's `OBJECTS
DESTINATION` which may be unwanted. Support skipping this component
with a target property.
`postCTest` and `postCMakeInstall` are more closely aligned with the
corresponding snippets which cause cause them to trigger (`ctest` and
`cmakeInstall`, respectively), and as such serve as better indicators of
their true behavior.
Compilation is complicated. Caching / distribution is even more
complicated. Sometimes there are bugs (in compilers as well as in
FASTBuild), so export the option to disable those features for CMake
targets.
Add a `CUSTOM_CONTENT` argument to `cmake_instrumentation()` for collecting
custom content from configure time.
Snippet files include a reference to a JSON file containing any `CUSTOM_CONTENT`
that was added by this command.
Fixes: #26703
Since most of the find modules use the `<PackageName>_FOUND` result
variables, this now also syncs it for the FindPkgConfig module. The
`PkgConfig_FOUND` result variable is available since CMake 3.3 and
contains the same value. There is also `PKGCONFIG_FOUND` result variable
automatically set with the same value but for simplicity isn't
documented. The uppercased `<PACKAGENAME>_FOUND` result variables set by
find modules are also considered legacy variables.
Create a brand new implementation of `cmTarget::GetMappedConfig` which
prioritized a target's `IMPORTED_CONFIGURATIONS` as the 'source of
truth' for what configurations are available. In particular, this means
that configuration selection when `IMPORTED_CONFIGURATIONS` is set does
not depend on the library type in any manner. The fallback logic also
uses a more consistent 'usability' criteria that should result in more
consistent configuration selection, particularly for `INTERFACE`
targets.
The previous implementation is retained as a separate method for users
requesting the OLD behavior.
Fixes: #27022
The references to the <ORIGIN>_autogen and
<ORIGIN>_autogen_timestamp_deps anchors were being replaced by the
section heading text that immediately followed the anchors. But in most
cases, the text where the cross-referencing was placed was expecting the
anchor text to be used instead. Add custom text for such cross-references
so that the text reads as originally intended.
- Used "commands" instead of "functions".
- Added separate examples section.
- Moved FOUND_VAR argument to the bottom as it is deprecated.
- Reworded descriptions.
CMakeGraphVizOptions is not a module to be included in a project, so
to make the Graphviz functionality clearer, this moves all its
documentation under the --graphviz option.
Fixes: #27110
This adds a new section in the modules index to move some internal
modules out of the main two lists - utility modules and find modules.
They are not intended to be used by projects.
Additionally, SquishTestScript is not technically deprecated module. It
is just internally used by FindSquish module and mistakenly documented
and rendered.
Issue: #26851
Due to how the default value of the CPACK_PACKAGE_FILE_NAME variable
is implemented, the packageName and packageVersion fields of packaging
presets don't affect the final package file name. They can still affect other
aspects of the package produced, depending on the package generator
used, leading to inconsistencies in the generated package. There is no
warning or error about this when producing the packages, and fixing the
implementation is non-trivial. Until such a fix can be made, add a note to
the docs to make users aware of this unexpected behavior.
Issue: #25248
The historic implementation of `$<CONFIG>` had some errors that could
result in multiple configurations matching. First, it always considered
the configuration of the consuming target, even if a consumed imported
target selected a different configuration. Second, it matched the entire
list of `MAP_IMPORTED_CONFIG_<CONFIG>` configurations, even if none of
those were actually selected. The latter in particular is redundant at
best, as we also consider the selected configuration of an imported
target, which is the correct configuration to match for imported
targets. Refactor the implementation so that only one configuration is
considered.
Fixes: #23660
Issue: #27022
Brad King