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
Fix a typo from commit 660e0d80ae (internal/CheckCompilerFlag: rely on
common configuration, 2022-01-12, v3.23.0-rc1~124^2~1) that caused
locale environment variables to not be restored after they are set
during the check.
The feature needs a specialized implementation to place headers
in the right place inside frameworks. To avoid silently doing
the wrong thing, make this case an error for the 3.23 series.
Issue: #23386
The MSVC `/FI` flag accepts an attached value or a following argument.
Previously our flag tables only had entries for the former. Add
the latter.
Fixes: #23382
Improve the logic added by commit f0e67da061 (target_link_libraries: Fix
out-of-dir linking of a list of targets, 2020-01-14, v3.17.0-rc1~149^2)
to, while exporting targets, look up referenced target names in the
correct directory.
The `GET_ARRAY` and `MEMBERS` modes were removed during development and
review of commit 8eab76eb84 (string(JSON): Adds JSON parsing support to
the string command, 2020-08-24, v3.19.0-rc1~159^2), but were
accidentally left in an error message.
Revert commit dd9584b352 (GNUInstallDirs: Apply Debian multiarch LIBDIR
to more prefixes, 2021-11-19, v3.23.0-rc1~323^2). There are separate
problems with activating multiarch `LIBDIR` for each prefix it added:
* Prefix `/` is often used to stage an installation with `DESTDIR`
for inclusion in a tarball package or similar.
* Prefix `/usr/local` is the default `CMAKE_INSTALL_PREFIX`, causing
the multiarch `LIBDIR` to be cached after the first configuration,
even if the prefix changes later.
Revert the change for now, except for the documentation update.
Further discussion will be needed to select a way to enable
multiarch `LIBDIR` for `/` and `/usr/local`.
Fixes: #23365
Issue: #19698
05e510bf0b CMP0132: Don't set compiler environment variables on first run
774a9eb210 Tests: Reorder CMP0129 test
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7108
`CMAKE_<LANG>_COMPILER` may be a list if it was defined by a toolchain
file. In this case we move the args to `CMAKE_<LANG>_COMPILER_ARG1`.
If `CMAKE_<LANG>_COMPILER` is not a list, then it might have been cached
by a previous run that split the `CC` or `CXX` environment variable into
`CMAKE_<LANG>_COMPILER` and `CMAKE_<LANG>_COMPILER_ARG1`. In this
latter case, avoid clobbering `CMAKE_<LANG>_COMPILER_ARG1`.
Fixes: #23358
When running CMake for the first time in a build tree, for some
generators CMake would set compiler environment variables
like CC, CXX, etc. when the corresponding language is enabled.
That behavior was never documented and can result in different
behavior between the first and subsequent runs. Add a policy
to no longer set those environment variables.
Fixes: #21378
Brad King