There's no control over the object base name implemented in the
FASTBuild generator. Rather than expecting some half-supported behavior,
just ignore it completely there.
Similarly, Xcode ends up making its own object paths internally
regardless of what CMake would like.
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.
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.
Update experimental UUID for instrumentation after commit fbb5b47fbf
(instrumentation: Rename postTest and postInstall hooks, 2025-09-04)
broke old hook names.
`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.
Update experimental UUID for instrumentation after commit bf52fbfbc4
(instrumentation: Add Google trace output, 2025-08-28) introduced a
significant feature.
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.
Explicitly state that if `<PackageName>_DIR` is set, but the version of
the package found there does not match the requested version, then
`find_package` will ignore that directory and continue searching.
- This deprecates the OPENCL_VERSION_STRING result variable.
- Documentation adjusted.
- Support for OpenCL 3.0 was added in CMake 3.24.
- Added CL_TARGET_OPENCL_VERSION compile definition to test so that
program compiles without warnings.
- Additionally, on Apple systems compiler can't find <Headers/cl.h>
unless direct path would be passed as a header. Instead, <OpenCL/cl.h>
is used for version check conditionally.
Issue: #27088
This variable in current CMake versions doesn't seem to be needed in any
case. Either if the UsewxWidgets is created in the project's own
CMAKE_MODULE_PATH location, or if FindwxWidgets is "forked" into project
own modules, include(UsewxWidgets) always includes the wanted file.
This deprecates the QT_VERSION_STRING result variable.
The QT_VERSION_STRING was probably meant to be set also by FindQt4
module (for the deprecated FindQt) but at the time of writing isn't
implemented therefore replaced in the test.
Issue: #27088
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