c5b56b35c2 cmInstallExportGenerator: expose the temporary directory
c107760417 cmNinjaTargetGenerator: support msvc-style deps discovery for scanning
64c15ec018 cmNinjaTargetGenerator: add flags for scanning based on the fileset type
aaa18f15cf cmTarget: add support for querying all file set names
cc4e19710d cmGlobalNinjaGenerator: use an extention based on the modmapfmt
97a68198c9 cmGlobalNinjaGenerator: escape `:` in module names
499009b79c cmTarget: avoid creating export entries if they don't exist
0513a1fe10 cmInstallGenerator: use CMake-private variables in generated code
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !7214
This needs to be known so that C++ module properties for the install can
be staged beside the other files.
Always perform the MD5 transformation (in non-bootstrap builds) so that
the path can be computed prior to generation (where it used the longest
configuration name to detect too-long paths). Update tests to expect the
always-present MD5 value. Note that this improves robustness of the test
suite as testing in a too-long path may have triggered the MD5
conversion anyways.
9916d4dd44 cmTarget: factor out fileset type handling
79d6b928a3 RunCMake/target_sources: test `HEADERS` file sets via generic props
d74f9599f6 cmTarget: require filesets to be of the right type
5da4fe30a9 cmTarget: factor out fileset property manipulation
c89580487b cmTarget: pass candidate strings by const-ref
64ea1a272c messages: remove screamake from comments and errors
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !7145
CUDA's cupti library has its headers in a seperate directory on a
standard CUDA install, but `CUDA::cupti` only adds the default cuda
include directory.
Issue: #22761
Several tests specify use of C++98 mode since commit b0f277db38 (HP aCC:
record compiler flag for Ansi C++98 support for version 3.80 onwards,
2014-04-15, v3.1.0-rc1~550^2). The motivating use case for those
changes was dropped by commit 49640d3629 (HP-UX: Drop support for
building CMake on HP-UX, 2017-08-04, v3.10.0-rc1~304^2), so remove the
use of C++98 mode too. Also remove code that, on some compilers, used
C++11 instead of C++98, because we can now just use their default mode.
Verifying the architectures during compiler identification is redundant,
and requires a lot more up-front information than we should need.
It also causes unsupported architectures to break the compiler id and
version detection, so the resulting output from CMake does not report
the compiler version, which is useful information to know why the
specified architectures are not supported.
The "detecting compiler ABI info" and "check for working compiler" steps
already pass `CMAKE_CUDA_ARCHITECTURES` into their test projects.
Therefore we can just drop the earlier architecture testing. Bad
architectures will be reported as a not-working compiler, and the
output will include the compiler's error message.
This reverts the approach from:
* commit 19cc5bc296 (CUDA: Throw error if user-specified architectures
don't work, 2020-05-26, v3.18.0-rc1~79^2)
* commit 650c1029a0 (CUDA: Detect non-working user-specified architectures
on NVCC, 2020-05-28, v3.18.0-rc1~51^2)
* commit 01428c5560 (CUDA: Fail fast if CMAKE_CUDA_ARCHITECTURES
doesn't work during detection,
2020-08-29, v3.19.0-rc1~241^2).
Their goal was in part to avoid waiting until the test for working
compiler to detect unsupported architectures. However, experience has
shown that failing earlier is more trouble than it's worth.
Fixes: #23161
Issue: #20756
Previously a fileset with `$<$<CONFIG:Debug>:some_file>` would show up
as-is (with escaping) in the build directory export. Instead, evaluate
all fileset entries as generator expressions and list them as they are
similar to the installation information.
Since macOS 12.0 deprecated the tools needed to attach a SLA to a
`.dmg`, we should no longer do this by default. Add a policy to
change the default to off.
Fixes: #22978
If an INTERFACE library has HEADER_SETS, and its header sets contain
files generated by a custom command, the library needs to participate in
the buildsystem so that the files will be generated.
Fixes: #23422
Added test to cover handling of when `CMAKE_OSX_ARCHITECTURES` differs from
OBJECT library target's `OSX_ARCHITECTURES`:
TargetOverrideSingleArch:
- When `CMAKE_OSX_ARCHITECTURES` is set to multiple archs,
- But OBJECT library's `OSX_ARCHITECTURES` is set to single
- Assert that OBJECT library target "`HasKnownObjectFileLocation`" and is
installable
TargetOverrideMultiArch:
- When `CMAKE_OSX_ARCHITECTURES` is set to single arch,
- But OBJECT library's `OSX_ARCHITECTURES` is set to multiple
- Assert that OBJECT library target does not "`HasKnownObjectFileLocation`"
and hence not installable
5fa15ec9f3 Help: Document that target_sources defines [INTERFACE_]HEADER_SETS
c5d4812f20 cmTarget: make HEADER_SETS and INTERFACE_HEADER_SETS read-only
05783b168d cmFileSet: store visibility with the fileset
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7168
5fa15ec9f3 Help: Document that target_sources defines [INTERFACE_]HEADER_SETS
c5d4812f20 cmTarget: make HEADER_SETS and INTERFACE_HEADER_SETS read-only
05783b168d cmFileSet: store visibility with the fileset
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7168
There is no reason to allow these properties to be manipulated by user
code. Instead, use the stored visibility on the fileset objects to
derive what these properties should contain.
When the Apple linker sees -headerpad_max_install_names and
bitcode is enabled with a flag like -fembed-bitcode, it issues a warning
and ignores the -headerpad_max_install_names flag. This causes
unrelated compiler and linker flag checks to fail for valid flags.
In f745e0497e (CheckCompilerFlags: Catch linker warning about ignored
flags, 2022-01-03), we started detecting linker warnings, which caused
a regression for projects that were setting -fembed-bitcode in their
CMAKE_CXX_FLAGS or similar. Prevent that regression by removing
the -headerpad_max_install_names linker flag when we know it will
warn and be ignored anyway.
Fixes: #23390
Issue: #23408