Since commit f593b354da (PCH: Add support for multi architecture iOS
projects, 2020-04-02, v3.18.0-rc1~414^2) the `OSX_ARCHITECTURES` target
property (and corresponding `CMAKE_OSX_ARCHITECTURES` variable) affects
flags on non-Apple platforms by accident. Add a missing condition to
avoid this.
Fixes: #21072
bafa9fe887 fileapi: Add INTERFACE libraries with SOURCES to codemodel-v2
4391913133 Add INTERFACE libraries to generated buildsystem if they have SOURCES
afb998704e Remove filtering of allowed INTERFACE library properties
e7edba2baf Makefiles: Use IsInBuildSystem in global generator target type checks
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5078
ecc1961768 FindTclsh: Drop Cygwin-specific behavior and use POSIX code path
af666acdf4 FindOpenGL: Drop Cygwin-specific behavior and use POSIX code path
8edbc59e46 install: Use case-sensitive pattern matching on Cygwin
24482499ea FindPerlLibs: Add versioned perl library name for Cygwin
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5092
INTERFACE libraries with SOURCES now appear in the generated
buildsystem, so include them in the codemodel output too.
We do not need to bump the `codemodel-v2` object kind minor
version because that was already done in post-3.18 development
by commit 7d6861f367 (fileapi: Extend codemodel targets with
language standard, 2020-06-18).
Fixes: #18608
INTERFACE libraries were created with the intention of collecting usage
requirements for use by other targets via `target_link_libraries`.
Therefore they were not allowed to have SOURCES and were not included in
the generated buildsystem. In practice, this has become limiting:
* Header-only libraries do have sources, they just do not compile.
Developers should be able to edit those sources (the header files)
in their IDE.
* Header-only libraries may need to generate some of their header
files via custom commands.
Some projects work around these limitations by pairing each interface
library with an `add_custom_target` that makes the header files and
custom commands appear in the generated buildsystem and in IDEs.
Lift such limitations by allowing INTERFACE libraries to have SOURCES.
For those with sources, add a corresponding build target to the
generated buildsystem.
Fixes: #19145
f76c20da63 Toolchain: Test compiler initial settings
db486da265 Toolchain: Update documentation for initial compiler flags
deec2f587c Toolchain: Take CMAKE_<lang>_FLAGS_INIT into account during compiler detection
ca899af3e2 Toolchain: Handle repeated invocations of CMake with -DCMAKE_C_COMPILER
12ba89e142 Toolchain: Make `/path/comp;-argn' behave the same as 'comp;-argn'
6f1af899db Toolchain: Capture all arguments from CMAKE_<LANG>_COMPILER
ec1d3bc0b6 cmake: avoid exception when printing "changed variables" message
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4136
The AutoMoc timestamp creating custom command explicitly depended
on all dependencies of the origin target (associated to the AutoGen
target).
When an origin target depended on a shared library 'libfoo.so',
if it was re-linked, the AutoMoc custom command would touch its
output timestamp file, and thus cause needless rebuilding of sources,
despite the shared library not having any influence on the AutoMoc
generated files.
Introduce a new '<target>_autogen_timestamp_deps' utility target,
which will serve as an 'order-only' dependency for the custom command.
This will prevent needless rebuilding, because touching 'libfoo.so'
will not cause the custom command to be re-executed.
The new AutoMoc dependency tree looks like:
'_autogen_timestamp_deps (serves as order-only dep)'
<- '<target_autogen>/timestamp' file ( + moc deps file)
<- '<target>_autogen' target.
Fixes: #21020
In commit 99ed39b011 (Ninja Multi-Config: Make link response files
per-config, 2020-07-15, v3.17.4~3^2), we added the target directory to
the response file under the mistaken assumption that two different
targets with the same name could be in different directories. However,
this causes the path to the response file to be too long to fit on a
command line. Take the path back out, while leaving in the per-config
split.
Fixes: #21050
Previously we disallowed use of arbitrary properties on INTERFACE
libraries. The goal was to future-proof projects using them by not
allowing properties to be set that may affect their future inclusion in
the generated buildsystem. In order to prepare to actually include
INTERFACE libraries in the generated buildsystem, drop the filter and
allow arbitrary properties to be set.
Issue: #19145
Brad King