b573a732dc Tests: add tests to check claims in the documentation
b151db01f9 Help: mention non-existent case for list(PREPEND)
b3a249c2cb Help: clarify range for list(INSERT), mention nonexistent / empty case
b6fdcb3df0 Help: clarify description of list(INSERT)
e55f473ea9 Help: clarify that list(APPEND) on a non-existent list creates it
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6824
Check the complete include path for being a system include, not
the derived framework search path. The code for Ninja and Makefile
generators does exactly the same.
Fixes: #23011
Changes in cmVisualStudio10TargetGenerator::Generate to write .Net
SDK-style project for VS generators VS 19 and above. Also adds
documentation and tests.
Issue: #20227
- mismatched comments and code,
- remove superfluous log of the "Real package" (which can
still change! log the changed filename if it does),
- the "fix up the package name" code was replacing the
pkg 1.17 suffix by the pkg 1.17 suffix, so it wasn't
really being useful. Whether **any** of the backwards-
compatibility packaging code is useful is another thing.
When using libpkg, the output filename is determined by libpkg
itself, based on information in the manifest: package name and
version, basically. This doesn't necessarily match the name that
CMake has determined via CPACK_TEMPORARY_PACKAGE_FILE_NAME or
CPACK_PACKAGE_FILE_NAME. So reset the CMake-determined list
to match what libpkg will do.
The pkg_create_from_manifest() function was never really intended as
stable API, and bapt@ has asked me to stop using it so the public
API can be stabilized.
Port to pkg_create() with its attendant settings struct.
Since we already have a complete manifest file, we can hand
that (including the embedded plist) to pkg_create().
While here, reintroduce pkg_init(), which lived in downstream patches
for a while and then went away again.
Optionally verify that items in `LINK_LIBRARIES` and
`INTERFACE_LINK_LIBRARIES` that can be target names are actually target
names. Add a `LINK_LIBRARIES_ONLY_TARGETS` target property and
corresponding `CMAKE_LINK_LIBRARIES_ONLY_TARGETS` variable to enable
this new check.
Fixes: #22858
Previously this module only provided `GLUT_INCLUDE_DIR`, which does not
follow the modern naming convention documented in `cmake-developer(7)`.
Issue: #23018
ea050286e7 CMP0028: Report the target whose link interface has an offending item
a97c92e46e CMP0028: Report backtrace to link item rather than target creation
0dcbf4ab58 cmGeneratorTarget: Record when imported target link iface libs are done
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !6810
Since commit f90d15458a (FindGLUT: Use pkg-config to find flags if
available, 2021-06-11, v3.22.0-rc1~469^2) we return early if pkg-config
provides the information. During review of that commit, code to
populate the legacy `GLUT_INCLUDE_DIR` result variable was removed from
that code path. Add code to provide it.
Also fix the test case to use `GLUT_INCLUDE_DIR`, the result variable
documented officially by the module.
Fixes: #23018
The RunCMake.GeneratorToolset test expected platform toolsets to have a
name beginning with 'v' followed by one or more decimal digits, as all
the Microsoft platform toolsets follow that naming convention.
The Intel platform toolsets begin with "Intel" and have various
additional strings depending on the compiler version.
This change accepts the toolsets delivered by Intel in addition to those
from Microsoft.
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
Add a `--debug-find-pkg=` option to debug find calls for specific
packages.
Add a `--debug-find-var=` option to debug find calls for specific
return variables.
Fixes: #21880
Brad King